|This article brought to you by LWN subscribers|
Subscribers to LWN.net made this article — and everything that surrounds it — possible. If you appreciate our content, please buy a subscription and make the next set of articles possible.
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:
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:
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:
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:
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.
Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds