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 the bugs listed on the python.org bug tracker.)

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 all be 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 prior

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 the arrow 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.

If you are typing at the interactive shell prompt, then want to go to the beginning of the line by hitting the Home key, you’ll then have to hit the right arrow key three times to *really* get to the front of the prompt. Until then, typing characters on the keyboard have no effect.

1.2) NEW FEATURE: Auto-Copy-On-Highlight

Once we get rid of being able to move the cursor off the last line, that opens a new opportunity to implement an automatic copy-on-highlight feature that many terminal and IRC client programs implement. Since this text is read-only, the only reason a person has for highlighting it is to copy it (they can’t delete it.) As soon as the user highlights text in the shell window, it is copied to the clipboard.

2) PROBLEM: When debugging, the current line of code loses its highlighting when the window loses focus. And the debugger window is a separate window so the file editor is forced to lose focus to operate the debugger.

Page 1 of 3 | Next page