The future of Python's IDLE

By Jake Edge
April 10, 2013

Python prides itself on being a "batteries included" language. That means it ships with many things in its standard library that other languages leave to various kinds of extensions. Perhaps somewhat surprisingly, one of those "batteries" is an integrated development environment (IDE) called IDLE. But the needs of an IDE differ from those of other, more library-like portions of the standard library, to the point where an exception has recently been made to allow for new IDLE features in Python maintenance releases.

Back in November 2012, a longstanding IDLE bug regarding the right-click context menu was fixed for Python 2.7, 3.2, 3.3, and the still-under-development 3.4. The change was something that would only be visible to those actually using the program (it added Cut, Copy, and Paste entries to the menu), but it ran afoul of the policy that no new features be added for Python versions that are in maintenance mode. That means that only Python 3.4 can benefit from new IDLE features. There was disagreement both in the bug and in a thread on the python-dev mailing list over whether the change should even be considered a feature.

But there is more to the issue than that. IDLE is partly meant to be a teaching tool that may be the first "Python" a new user sees. For a program like that to differ between the various versions of Python would be unfortunate, as would holding back progress on IDLE in the still-dominant Python 2.7 series. Those needs and the dispute over the menu changes led Nick Coghlan to call for a Python Enhancement Proposal (PEP) that would exempt IDLE from some or all of the maintenance mode restrictions.

There was a bit of pushback against the idea that a PEP was needed, but Coghlan tried to make it clear why it was the right approach:

If you don't want to run the risk of needing to rehash this discussion every time an IDLE feature addition is made in maintenance branches, write the rules down in a PEP.

I don't actually care all that much about IDLE (except in an abstract "I know other people care about it" sense), but I *do* care about developers being able to understand the rules about whether or not a feature addition is permissible in a maintenance branch. That kind of thing *cannot* be left to "oh, this change is OK, this change isn't, but you needed to be around for this discussion that happened 5 years ago in order to understand why", because it *wastes everybody's time* explaining the unwritten rules to new developers.

In February, Todd Rovito posted a proposal (PEP 434) . As described in the PEP (which is also available in the official PEP repository), one of the main motivations behind IDLE is to provide a standard teaching environment across all versions of Python:

IDLE is a important "battery" in the Python toolbox because it allows a beginner to get started quickly without downloading and configuring a third party IDE. IDLE represents a commitment by the Python community to [encourage] the use of Python as a teaching language both inside and outside of formal educational settings. The recommended teaching experience is to have a learner start with IDLE. This PEP and the work that it will enable will allow the Python community to make that learner's experience with IDLE awesome by making IDLE a simple tool for beginners to get started with Python.

After the PEP was discussed in February on the python-ideas mailing list, then was reworked by Terry Reedy in early March, the discussion about it was rekindled after PyCon. As noted by Eli Bendersky, one of the teachers of a "Young Coders" workshop at the conference, Katie Cunningham, mentioned IDLE in her blog post about the experience. The free workshop used Raspberry Pi computers running the Raspbian distribution to teach Python to children. While IDLE was used "because it's already on Raspian's desktop", she was not completely happy with it: "Too bad it's broke as hell."

Bendersky used that post as a jumping off point to ask whether IDLE should be removed from the standard library altogether and be treated as a separate project. His contention is that IDLE reflects badly on Python because "it's badly maintained, quirky and ugly". But, as Rovito pointed out, there is more to Cunningham's message that should also be considered:

I think the next paragraph from the article is important as well:
"I believe my first contribution to the Python Standard Library will be fixes to IDLE. I really do like it that much. Happily, the kids were flexible. If they needed to do a workaround, or ignore something on our slides (they were written with the standard shell in mind), they did so. They were total champs. My adult students would have been much more upset."

There is currently a fair amount of activity in the IDLE world. Bugs are getting fixed, and it is being used as a teaching tool in various settings. Many of the core developers, including benevolent dictator for life (BDFL) Guido van Rossum, don't use the tool at all, so they have little interest in doing the reviews needed for IDLE changes to get into the Python mainline. There is also something of an impedance mismatch between the core Python release cadence and the needs of a user-facing program like IDLE. There are thoughts that it might eventually be moved out of the standard library (in a Python 3.4 or 3.5 time frame), but that is somewhat contentious too. When it was suggested that Van Rossum simply remove IDLE, Coghlan asked for some time to work things out:

Please don't rush this. We have Roger Serwy being given commit privileges specifically to work on Idle, Terry's PEP proposing to make it explicit that we consider IDLE an application bundled with Python that can receive new features in maintenance releases and several people expressing interest in helping to make IDLE better (primarily educators, including Katie Cunningham, one of the teachers who ran the Raspberry Pi based Young Coders sessions for teens and pre-teens here at PyCon).

In fact, Coghlan went further than that, accepting PEP 434 on March 30 (as the "BDFL delegate" to decide on the PEP's fate). On his blog, Coghlan explained that volunteering for the Young Coders workshop at PyCon had changed his perspective on IDLE and what its role should be. Going forward, IDLE will be able to be enhanced in the standard library for all versions of Python.

There is still a lot of interest in seeing IDLE move out of the standard library—eventually—but having an IDE available as one of the included batteries with the language is popular with educators and others. Down the road, shipping an installation tool for PyPI packages in the standard library may alleviate some of the concerns about removing IDLE. But for now there appears to be something of a renaissance going on in the IDLE world—it will be interesting to see what comes of that.

to post comments

The future of Python's IDLE

Posted Apr 11, 2013 3:06 UTC (Thu) by dashesy (guest, #74652) [Link] (13 responses)

PyDev+Eclipse is a professional IDE for Python, it is free and open source too (I hope it remains so [1], by getting the love it deserves).
Anything short of iPython and PyDev will not get attention of the new users from my generation let alone current *App* generation.
Fortunately there are great tools such as Spyder to persuade MATLAB users (my wife) to convert to Python. New users after installation (on Windows because that is where most new users are), see the shortcut for IDLE, if it does not scare them they may start learning about it until they realize they have wasted valuable time because Python actually has many modern environments that support more than Copy/Paste.

[1] - PyDev and LiClipse for a Fast, Sexy -- and Dark Eclipse

The future of Python's IDLE

Posted Apr 11, 2013 7:31 UTC (Thu) by Cato (guest, #7643) [Link]

Worth supporting that Indiegogo effort for PyDev and LiClipse (a lightweight Eclipse allied to this - would be great to see an open source IDE for Python to give PyCharm (closed source but good) some competition.

The future of Python's IDLE

Posted Apr 12, 2013 9:45 UTC (Fri) by juliank (guest, #45896) [Link] (9 responses)

Be serious. Eclipse should be exterminated. It's just a really large piece of Java crap. It's not suitable for sane stuff.

The future of Python's IDLE

Posted Apr 12, 2013 15:30 UTC (Fri) by dashesy (guest, #74652) [Link] (8 responses)

I am not a big fan of Java, but you should give Eclipse a second try. Make sure to have 12GB of RAM and everything will be smooth and fun. You can even index the entire kernel in it and use "Go to definition" to learn about how a large code base is structured.
I almost never *run* anything there, but it is great to write code. I think I am spoiled by code-assist features, once vim will integrate better with clang I may go back and use it again but for now I have no problem with buying more memory.

The future of Python's IDLE

Posted Apr 12, 2013 15:40 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

I've been attempting Android development a couple times and Eclipse kept draining all the fun out of it (awful cluttered UI, forgetting options/plugins on upgrades forcing me to reinstall the ADK and Eclim every time, etc.). Now that Qt 5.1 (alpha) has Android as a target, I've been trying to get it installed, but -prefix doesn't seem to work :( .

The future of Python's IDLE

Posted Apr 12, 2013 15:59 UTC (Fri) by dashesy (guest, #74652) [Link] (1 responses)

Yes, the clutter is not fun. One thing however that I learned is to have multiple Eclipse installations, like the ADT bundle just for Android, or Aptana for Python (hopefully LiClipse in the future). At first it might look tempting to go through the plugin path, but I never want to develop Python, Android, and some microchip at the same time.
BTW, it is great to know Qt5 has Android as target now! the less exposure to Java is appreciated.

The future of Python's IDLE

Posted Apr 12, 2013 16:14 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I was really only interested in Eclipse for Android. For everything else I use Vim (which handles multiple languages just fine[1]). Installing Eclipse multiple times sounds like a nightmare to maintain. Maybe the only thing left yet is the resource editors in Eclipse. Though I think Qt probably handles this cleaner anyways.

[1]Between Ggrep, NERDTree, and command-t, navigating a source tree is a breeze. About the only thing I was really jealous of in Eclipse was the UI builder.

The future of Python's IDLE

Posted Apr 13, 2013 7:54 UTC (Sat) by IkeTo (subscriber, #2122) [Link] (4 responses)

I've used Eclipse a few years back. A big memory hog, yes, but that's not what I hate about it. In Eclipse, I was expected to create a project to start any work, and the system owns the file there not me (if I do the wrong thing it can delete or otherwise manipulate any of my files). That alone kept my blood pressure high, especially when I have to fight against the workspace to make it know / forget about files. Then there are multiple "perspectives" of the same project, which I never know why I need them, but if I accidentally get to another perspective all my original arrangements of windows are gone. Then in any perspective there are many windows showing essentially useless information (the module tree, the warnings, the docs, etc) which keeps popping out, leaving little screen estate for the actually important information (the code). The same concept is shown in many windows (do you really need a window for version control, another for file list, and another for packages, and yet one more for outline?). Even running the program properly requires quite a bit of training: many times I ended up running many copies of the same program without knowing, and seeing improper behavior until I know the reason many moments later.

Perhaps I'm just too used to coding with Emacs/Vim with a proper console, a heavy IDE simply doesn't work for me. Too bad that Java expects people to use an IDE (how come identifiers are 30 characters long?!), but luckily we have Python and C / C++.

The future of Python's IDLE

Posted Apr 13, 2013 10:49 UTC (Sat) by paulj (subscriber, #341) [Link] (2 responses)

The Netbeans IDE is fairly sane, in that it's easy to make it use an existing build system. Also, Netbeans is pretty good at documenting what you do need to do to make that build system support Netbeans, e.g. like adding targets to run the Netbeans profiler (which is the only Java profiler I know in the Fedora repos that can actually profile the whole lifetime of the app, from startup, without fuss).

The future of Python's IDLE

Posted Apr 13, 2013 12:06 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Oops, that possibly should be "existing ant build system". Ant isn't a terribly build tool though.

The future of Python's IDLE

Posted Apr 16, 2013 18:14 UTC (Tue) by k8to (guest, #15413) [Link]

I would say ant is a terrible build tool, except for all the others being just as bad.

The future of Python's IDLE

Posted Apr 13, 2013 18:04 UTC (Sat) by dashesy (guest, #74652) [Link]

Yes perspectives and that debug perspective does not close once debugging is finished is unnerving, one more reason I use Eclipse just to write code and not debugging. Anyways, I have to rearrange every possible perspective once (if I lose my settings), but next time it will be the way I like. For me most of the perspectives are identical after this.
I usually dock almost any of the code-related windows (outline, modules, ...) to one right panel, and all of the runtime related ones (console, variables, ...) to one bottom panel, and the code takes the center and left side; on a dual-screen I also stretch the main window horizontally to get the right panel out of the first monitor, leaving more room for code. When I am focusing more on the code I double-click on the code tab, and it maximizes (essentially minimizing all the bloat out of sight).
Yes the most annoying part about Eclipse is that you may end up running the same code twice, when you think the perspective is not debug, or simply thinking it might resume from a previous breakpoint!! Again one more reason not to do that, treat Eclipse just like a fancy editor with very nice code-assist features. If printf is not enough, I have vim+gdb, or iPython on a second desktop just for debugging.

The future of Python's IDLE

Posted Apr 17, 2013 12:16 UTC (Wed) by smitty_one_each (subscriber, #28989) [Link] (1 responses)

GNU/Emacs.

The future of Python's IDLE

Posted Apr 23, 2013 11:54 UTC (Tue) by nix (subscriber, #2304) [Link]

With which of the half-dozen competing python modes, almost all called simply "python-mode"? Seriously, I live in Emacs and breathe Emacs -- my OS is more Emacs than Linux, to be honest, and a failure of my Linux box is more significant because it stops me using Emacs than for any other reason -- but its Python support is not the best for not confusing the flaming wombats out of people. (Though it is improving now, at last.)