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 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 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 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. (UPDATE: Fixed in 3.3!)

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. (UPDATE: Fixed in 3.3!)

And the debugger window is a separate window so the file editor is forced to lose focus to operate the debugger.

I’m sure this is due to some sort of tk issue, but it’s annoying.

3) PROBLEM: There’s no obvious way to stop a running program. (Don’t expect them to know Ctrl-C)

Beginners won’t know or be able to remember the Ctrl-C trick to interrupt some infinite loop. MIT’s Scratch has a good idea where the program is started by clicking on a green flag and stopped by clicking on the red stop sign next to it. A small red icon with a “Stop the current program” tooltip would be great, or at least having a menu to invoke a keyboard interrupt would be better than expecting them to remember a keyboard combination.

4) ANNOYANCE: Get rid of the detachable menus feature.

Enough said. Clicking on those “---------” options in the menu to make them into their own standalone windows is a weird feature that I don’t see anyone, especially beginner coders, make use of. Just get rid of them. No other software does that because if the user wants a shortcut to the menu, that’s what keyboard shortcuts are for.

5) PROBLEM: Opening a file editor window or a shell window isn’t clear.

On the shell window, you have File > New Window. This isn’t clear that it is opening a file editor window, as opposed to another shell window. It should be renamed to File > New Editor Window.

On the file editor window, you have Run > Python Shell to re-open (or re-focus if it is open) the shell window. Two problems: The Run menu is in the middle of the menu bar. This is an option that belongs under File. And second, “Python Shell” isn’t a clear way to say that it is going to open a new window. It should be moved and renamed to File > Python Shell Window (or maybe File > Shell Window) (UPDATE: I've changed my mind about this, but I think this is still something that could be sidestepped by having a single-window design.)

6) PROBLEM: IDLE crashes when you quit a Pygame game without calling pygame.quit(). (Update: Fixed in 3.3!)

I know this is probably some generic leftover-references problem, but Pygame is a fairly major library that new programmers use (game making being a big way people get into programming.) But I’d agree with the Raymond Chen/Sim City approach and go ahead and make a specific change to check if Pygame was loaded and pygame.quit() was not called by the time sys.exit() was called.

7) ANNOYANCE: It’s too easy to forget the .py extension when saving a file. (Update: Fixed in 3.3!)

My text editor detects when I’m trying to save a file without an extension, and offers to add the .txt extension. This is handy, especially given that IDLE’s file editor turns off syntax highlighting when the file doesn’t end with .py (even though you can still run this “non-python” file just the same).

8) NEW FEATURE: Get rid of the Windows > Zoom Height feature. Get rid of it and replace it with a standard “Tile Horizontally” and “Tile Vertically” option, so that  the shell window and the editor window can easily be both maximized and seen at the same time.

9) ANNOYANCE: Get rid of the Edit > “Show surrounding parens” feature. If anything, it should be done automatically all the time whenever the cursor moves around the file editor window.

10) PROBLEM: The Debugger UI needs to be cleaned up.

The user interface for the debugger is ugly. The four checkboxes are silly. The Locals and Globals displays don’t expand well when the debugger window expands. There are no keyboard shortcuts for the stepping buttons. You can’t adjust the size of the Locals display when the Globals display is open. Et cetera.

11) PROBLEM: The Configure IDLE UI needs to be cleaned up. (Update: Fixed in 3.3! Though I still see some changes that could be made.)

A slider bar for setting the standard indentation width? A select list for the font size instead of a combo box? The Ok and Apply buttons are always enabled even if no changes have been made? No “Reset to Defaults” button? The “Custom Highlighting” fieldset on the Highlighting tab needs to be redesigned. The “Autosave Preferences” should be settable from the dialog box that prompts you to save when you run a program.

And am I the only person who noticed that the Help button doesn’t actually do anything?

12) NEW FEATURE: Add an option to show line numbers along the left side of the editor window, and have it enabled by default. (Update: I'm on the fence about having this feature on by default. It's not so helpful when writing code, but is helpful for a teacher explaining a pre-made program the students are reading. The instructor can point them to line numbers in the code and they are immediately obvious where they are.)

The entire status bar is wasted screen real estate because it is only used for that tiny display of the current line and column. Also, why even bother having that status bar with line/column information for the shell window?

13) ANNOYANCE: The Indent Region and Dedent Region lines use the keyboard shortcut Ctrl-] and Ctrl-[, even though nobody uses that because you can indent the region by pressing tab. However, there is no dedent by using Shift-Tab. Add that.

14) IMPROVEMENT: Get rid of the Format > “Strip trailing whitespace” option from the menu, and just have an option where the editor can do this automatically when you save the file.

15) MODERNIZATION: The Save dialog asks “Do you want to save this untitled document before closing?” and then presents you with Yes, No, and Cancel buttons. Update this to use verbs instead of yes/no: Use Save, Don't Save, and Cancel.

16) ANNOYANCE: The Windows shortcuts for IDLE don't have the version in their name. This wasn't a problem for Windows XP and before, where you just go to the Python shortcut folder (which does have the version info in the name) and select IDLE. But in Windows 7, to launch a program you click Start and simply type "IDLE" to bring up all the IDLE-named shortcuts. Before I changed the shortcut names manually, it was impossible for me to tell which Python version's IDLE I would be starting:

17) NEW FEATURE: Ctrl-Scroll to change font size. (UPDATE from 6/4/2013) Much like how holding down Ctrl and scrolling the mouse wheel will zoom in and out, it'd be nice to have IDLE change its font size by doing this.

One last thing, I think it was a stroke of genius to include a small IDE bundled with the interpreter, especially one that was written in Python itself using the included GUI toolkit. It shows that the Python devs care not just about attracting seasoned developers but also about drawing new people into programming which (as PHP showed us) will turn into remarkable market share later on.

I also understand why IDLE isn't at the top of the priority list: people code away with it for a while, and then move on to a bigger and better IDE. It's a disposable IDE (though I mean that in the nicest possible way). But a few tweaks would improve its usability in that mode of improvement where people may not notice the quality, they just stop noticing any hangups. "It just works."

UPDATE (2014/2/17) - Also, it'd be nice if you could specify command line arguments when you run scripts in IDLE. (Hmmm... maybe this is going too far with the feature set though.)

UPDATE (2014/7/15) - Also, it'd be a good idea to include an integrated pip installer. Something like Sublime Text has for installing plugins.

UPDATE (2014/9/6) - It'd be great if IDLE could detect if the user is trying to run Python 2 code on Python 3 or vice versa. That's about half of the questions I get emailed to me.

UPDATE (2014/9/7) - Thinking about item 1 more, to better convey that you can't type new instructions while the cursor is off the last line, I'd move the final >>> prompt to a small separate window on its own at the bottom of the interactive shell window. This way, the top area is read-only (though the cursor can be moved there to highlight text) while it is understood that instructions are only entered at the bottom when the cursor is there. Also, I've seen cases with the kids I teach where they think of the interactive shell window as a word processor, and when they make errors they try to move the cursor back up to "correct" their code, rather than just retype it in.

UPDATE (2015/4/6) - I've outlined a plan for redesigning IDLE as an educational tool in this github wiki: IDLE Reimagined.

36 thoughts on “The Things I Hate About IDLE That I Wish Someone Would Fix

  1. Problem is, IDLE is not maintained by anyone. The couple of persons who will occasionally claim they *will* improve it "real soon now" generally don't do anything at all. Several people will yell, however, if you propose to kick it out of the standard library.
    Bottom line, if you want to contribute, you are fully welcome. You may want to post on but it is populated by these same people I talked about above.

  2. I'm a professor teaching Python. I want to add what my classroom problems about IDLE as well:

    1. ANNOYANCE: input() doesn't play well when re-running a script when the script is already running.

    Here's a use case. A student types this program in IDLE:


    x = input("Typ a word:")
    print (x)


    They run the code. In the shell window, the student would notice the mispelling. Without exiting the shell window, they would go edit the code and then press F5.

    The shell would still be running the previous code instead of restarting.

    In some of my exercises, the students would sometimes think their code are broken when in reality, they already got the solution. They were just running the older instance.

    This becomes common enough that I ask my students to exit the shell window before running their scripts.

    2. ANNOYANCE: Turtle does not play well with IDLE.

    Almost similar to pygame, if a student runs a turtle script without quitting the turtle window, the first turtle window would crash.

    Like in my 1st item, I just ask my students to exit the window before re-running their code.

    3. FEATURE: A syntax highlighting for blocks of code would be nice to have.

    Also, a different highlight colors for tabs and spaces would help establish the idea that students really shouldn't mix the two in their code.

    4. UNFRIENDLY: Forcing a kill of a running script by clicking the X close button brings up the scary message of "killing" something.

    1. 1. Appears to be fixed. When I hit F5 in editor while Shell in waiting for input, Shell restarts as it should.

      2. Ditto. I loaded a couple of the turtledemo/ demos and ran with F5. Hitting F5 again while demo is open, and demo closes, Shell restarts, and a new demo window opens. Closing the demo window causes a tcl error but that is an issue with how the demos are written, not with Idle.

      3. I presume you are referring to blocks of code in non-python files. Issue 6804 touches on this.

      4. Unless another developer objects, I will change 'kill' to 'stop'.

  3. You missed a couple. On Mac OS X, you click in a window to bring it back to the front. So if Idle is behind another window, and you click anywhere in it to bring it to the front, that random spot is where it also sets the cursor. So unlike any other mac app, you have to be extremely careful where you click -- either exactly in line with or below the last prompt, or on the title bar. Anywhere else and you can't type and have to click again lower down.

    Two, if you copy text from any other app and paste into Idle window on the prompt line, it locks up hard and has to be force-quit.

    In fact I can't imagine how or why you've used it to teach kids with - when Wing IDE 101 is available free.

  4. IDLE is so weird and works so differently from anything else that I find it incomprehensible, and as such probably not a good teaching tool at all.

  5. I use IDLE a lot in training classes and couldn't agree more with this post. I would add to this list that using IDLE on Mac OS-X is an absolute embarrassment right now. If you try it with the preinstalled Python, don't expect it to work for long (frequent freezes and beachballs requiring "Force Quit"). Even if you perform all of the magic incantations and upgrades of Tcl/Tk to make it work, it's slow, looks horrible and barely seems to work. Alas, no time to dig into the code to try and fix it ;-(.

  6. Excellent usability suggestions!

    Anyone know if the pygame crash can be fixed on the pygame side? That's at least one thing I could look into. Here is the issue on the pygame issue tracker:

    Also I wonder what the IDLE code base is like? Is there any architecture or development documentation for it? I can't find any.

    IDLE-dev Mailing list (maybe good to post your blog here):

    The source lives in Lib/idlelib I think.

    There's a CREDITS.txt in the Lib/idlelib directory with maintainers mentioned.

    Also, if any fixes are made soon, then they might be able to get into the python 3.3 release. But people using old pythons will be stuck with the bugs forever :(


  7. Have you tried Spyder's light mode for the console?

    I wish some subset of Spyder could come battery included for Python. I've raised the thread about replacing IDLE with "something else" two years ago, but there was no alternative

    With this post (and Python 3 in mind) the problem seems actual once more, but replacing IDLE will require distributing some other framework (like Qt + PySide) on Windows instead of Tkinter. Because the problem is not in IDLE, but in underlying platform, which is not used/supported anymore.

  8. Hello, retired IDLE developer here.

    I used IDLE for several years, both at work and for hobby Python programming. During this time I hacked at IDLE quite a bit. I fixed a few small things and also worked on major improvements such as auto-completion, extension configuration and improved search functionality.

    I found development to be an uphill battle during that time, with the Python devs hardly finding the time to review my patches and provide some guidance once every few months. Hardly anyone showed much interest in IDLE back then.

    Years passed, and a few others invested significant development efforts into fixing and improving IDLE. However, many of these changes have yet to be merged into the version of IDLE distributed with Python.

    Finally, about a year ago (maybe more?), I was given commit rights to assimilate improvements and fixes. However, since I was not using IDLE any longer, I simply couldn't find the time for this. Nobody has stepped up in my place (though admittedly I never officially "resigned" -- I always hoped to find the time...).

    In any case, thanks for taking the time to detail the bugs and annoyances you've found while teaching with IDLE. I hope this will motivate someone to breath some life back into IDLE.

  9. Hey nice article, I just found it. I agree with you on a lot of the complaints.

    Oh and hello Tal, I remember you replied to some postings of mine on idle-dev a few years back. Nice to see you around!

    Anyhow, I also love IDLE and I am thinking of maybe getting around to hacking some at it. This article is added motivation so thanks!

  10. Number 5 is definitely a good one. I learned how to program reading Invent With Python, and I typed most of the hangman game into the python shell before I realized something was wrong.

    With regard to number 12, on adding line numbers, there is some useful code at I used a modified version of that to attempt to add line numbers to my local copy of IDLE about eight months ago, but ran into some strange errors. I'm a much more proficient programmer now, so I might try again, and submit the code to the python people.

    One thing about IDLE I find very confusing is creating extensions. Documentation is negligible, and only covers creating an extension, without mentioning how the extension can interface with IDLE. If a simple "Hello World" extension were to be distributed with python that would be very helpful.

  11. I Used Python a few years ago and had several issues of figuring out modules and now Ive started back and everything seems to be working great for me in python 3.2.2 version. I may even teach a basic class in the future once I have all my ducks in a row. I would love to do development for Python some day

  12. "Auto-Copy-On-Highlight"

    If you do this, add a clipboard icon to the cursor when hovering over that text, so it's very obvious what selecting that text does. Don't make programs behave weirdly in different parts of the screen without a visual warning.

  13. Part of the problem is that IDLE's releases are tied into those of CPython, despite not having any of the same compatibility issues involved in releasing a changed language or standard library.

  14. My IDLE constantly fails to come up, talking about being block by a firewall .I find my self having to restart my computer. Admittedly, it seems to only happen on Python 2, but I need that for pygame.

  15. I just started writing a Sokoban clone using IDLE.
    I would like to show the line numbers, and search the internet for an answer. It is frustrated to find out there is no way to do this.

    Reply from Al:

    Yes, one of the frustrating things about IDLE is that you can't show line numbers in the editor. You can try a different editor, such as Notepad++.

  16. Quote: "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)."

    I'm new to Python, and I literally just discovered this tip by chance which may be useful to those students (it works in XP anyways):

    If you click on the text you want to edit and hit the Enter key, it copies the line to the active >>> prompt where it can be edited. It's much easier than copy-paste or retyping!

    1. I would like to add 'Undo run', perhaps cntl-shift-z, that would erase the last output, such as a traceback, and re-activate the previous input line to be edited.

      1. Are you sure this is a good idea? If it did set some variable (and even if it didn't, setting "_" implicitly), "Undo run" suggests a very wrong thing.

  17. I really, really hate the fact that you can only paste one line at a time into IDLE. If you paste more than one, only the first line "takes" and the others are silently ignored.

    Also I think that by default the up and down arrow keys should cycle through the command history. You can configure it this way but it's painful and not something a beginner could figure out unaided.

    1. Idle is statement rather than line oriented. One can paste a multi-line statement.

      I would prefer arrow-key history also, but am reluctant to change the default without taking a poll of users, which is not possible. I will think about this.

  18. i like the idle but i know there is lots of small problem which make it not very good, the idlex fix some of those problem but it also brought more problem as well...
    the only really good thing about the idle is the code context, it most likely the only reason i am still using the idle with add-ons call idlex

  19. For the record Terry Reedy et al has been doing a lot of work on IDLE in recent months, mainly as a result of getting PEP 434 accepted, see I'd be inclined to check out the bug tracker to ensure that problems listed above haven't already been fixed, or at least to see that there is a relevant issue.

  20. for number 4, the detachable toolbars you can simply edit line 447 of idlelib/ from:
    "menudict[name] = menu = Menu(mbar, name=name)"
    "menudict[name] = menu = Menu(mbar, name=name, tearoff=0)"

    this prevents any of the menus from detatching

  21. Have you considered using IPython Notebook or Colaboratory for teaching Python?

    You actually do get a "word processor" style interface, with a run button and an output window below. Which you can then chain together. It's pretty slick.

    Colaboratory keeps your notebooks in Google Drive and adds collaborative editing. There's a version that's packaged as a Chrome App, including a Python runtime in the PNaCl sandbox, so it's batteries included and even works on Chromebooks.

Leave a Reply

Your email address will not be published. Required fields are marked *