[Python-3000] What to do about IDLE?

Talin talin at acm.org
Sat May 6 11:30:00 CEST 2006


>From what I understand, the "mission statement" of Python 3000 is not to load
up the lanugage with a bunch of sexy new programming features, but rather to
"go back in time" and make small changes to the original Python design that have
turned out to be problematic in practice.

One of those problematic areas which has inspired much debate on this list
is the including of the Tk libraries. The libraries are certainly showing their
age, both in appearance and in API design. However, at the same time there
is a lot of capability there that will not be easy to replace.

There have been various proposals (which I won't go into here) for replacing
Tk; Whether an adequate replacement exists at the current time is debatable,
and should be the subject of a different thread.

Because IDLE uses the Tk library for its UI, it suffers from many of the same
problems. To be honest, I've always found using IDLE to be a relatively
painful experience; Just about any modern programmer's editor (I've used
SciTE, BBEdit, TextMate, and Emacs for this) does a better job as an interactive
Python development environment, not to mention the many Python IDE's
that are available.

Giving IDLE a modern UI, with even the most minimalist feature set found
in current-generation IDEs, would be a monumental task.

I'm sure that the question of whether IDLE should be fixed or dropped will
start a huge flamewar; But the alternative is to do nothing, which seems
even worse from my viewpoint.

I'd be curious to know how many Python developers actually use IDLE?
Moreover, if IDLE is going to stay, it should have a clearer mission
statement. Clearly IDLE is never going to be the top-end IDE for Python
development, so what is its purpose? To provide a "backup" in case a
top of the line IDE is not available? An introductory IDE for fledgling
Python programmers?

Here's an idea: Create a description of what IDLE *should* be. Then evaluate
the various UI toolkit proposals in light of whether or not they can support
that spec. If we feel that tree views (for a class hierarchy view) or toolbars
with tooltips are imporant, then the candidates for the UI toolkit should
be able to support that.

-- Talin




More information about the Python-3000 mailing list