[Python-Dev] Removing IDLE from the standard library (original) (raw)

Tal Einat taleinat at gmail.com
Sun Jul 11 16:22:28 CEST 2010

On Sun, Jul 11, 2010 at 11:57 AM, Tal Einat wrote:

I would like to propose removing IDLE from the standard library.

I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised: To those who mention that IDLE is "okay" or "not going uphill", my grandfather would say "if you aren't running forwards, you are falling behind." You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development. I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place. The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application? Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library.

Most of the responses up to this point have been strongly against my proposal. The main reason given is that it is nice to have a graphical IDE supported out-of-the-box with almost any Python installation. This is especially important for novice programmers and in teaching environments. I understand this sentiment, but I think that supplying a quirky IDE with many caveats, lacking documentation, some bugs and a partially working debugger ends up causing more confusion than good.

Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.

Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib.

More information about the Python-Dev mailing list