The Things I Hate About IDLE That I Wish Someone Would Fix I’ve written a book on Python programming for kids and complete beginners. I’ve also done some classroom and one-on-one teaching with adults and teens. I have them use IDLE, the IDE that comes with Python, because it is simple and easier than having them set up some other IDE (like PyDev on Eclipse). But over time I’ve noticed a lot of problems with IDLE that I wish someone would fix. (I’d like to do it myself but I don’t have the time currently.) I’m very, very grateful that Python comes batteries included vis-à-vis an IDE, but there are a lot of warts and user interface issues with IDLE. (These are different from .) First off, my philosophy is that no serious Python programmer uses IDLE as their dev environment. With that assumption, we can get rid of any need to cater to them and make IDLE aimed at people who are not only new to Python but new to programming in general. IDLE should be an education tool more than a development tool. This means that the IDLE default options should allbe set for the basic user, not the power user. With that in mind, these are things I’d like to see changed about the design of IDLE (roughly in order of importance and priority.) UPDATE: 2014/12/26 - It's been a few years since I wrote this article, and I've marked the issues that have been solved. Thanks, IDLE dev team! 1) PROBLEM: In the shell window, if you click anywhere but on the current line and move the cursor there, the window stops handling key strokes. This caused so many problems when I was teaching a dozen teenagers how to program in Python. Someone would accidentally click on the interactive shell window in the wrong place, and then the window would stop making text appear as they type and they have no idea why. I’d have to pause the entire class to figure out what happened, resume, just to have someone else do it ten minutes later. What would we lose by getting rid of this “feature”? Well, we wouldn’t be able to highlight text by holding down shift and banging on thearrow keys. That… hasn’t really been something my students and readers really need. The “select all” covers the case for highlighting everything, and the mouse can be used for highlighting small bits of text. The in-between amounts (where holding down shift and pressing PgUp or PgDn) is a special case that isn’t special enough to break this rule. Another UI problem that being able to move the cursor back up introduces: When my students' code would raise some exception, they thought they could correct it by scrolling back up, deleting the original code, and then re-typing it out (as if the interactive shell were a word processor). They would move the cursor up, but would be foiled when couldn't change any of the existing text. Getting rid of this misleading cursor stops this issue much earlier in the process and reduces confusion. 1.1) SUB-PROBLEM: Pressing the Home key moves the cursor before the >>> prompt, which then makes the keyboard unresponsive. (UPDATE: Fixed in 3.3!) If you are
