[Python-Dev] IDLE in the stdlib
tjreedy at udel.edu
Thu Mar 21 01:15:56 CET 2013
On 3/20/2013 2:22 PM, Eli Bendersky wrote:
> On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray <rdmurray at bitdance.com
> <mailto:rdmurray at bitdance.com>> wrote:
> On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky <eliben at gmail.com
> <mailto:eliben at gmail.com>> wrote:
>> Personally, I think that IDLE reflects badly on Python in more ways than
>> one. It's badly maintained, quirky and ugly. It serves a very narrow set of
>> uses, and does it badly.
Personally, I think running Python with the imitation-MSDOS Windows
Command Prompt (CP) reflects badly on Python in more ways than one. It's
anti-maintained, quirky and ugly, and for some uses is badly broken.
I am serious and am not just being sarcastic. I suggested years ago that
we try to find an alternative. Some details:
Ugly (and quirky): it imitates ancient white type on black background
CRT monitors. I do not know of anything else on Windows that looks like
Broken (and quirky): it has an absurdly limited output buffer (under a
thousand lines) that is over-flowed, for instance, by "python -m test".
In other words, by the time the test suite has finished, the early
results and error messages have scrolled off the top. Same can be true
of verbose repository pulls, doc builds, external dependency fetch and
compile, help messages, and any other substantial printing. For example,
start the standard interpreter, enter 'help(str)', page down to the
bottom, scroll back up, and the top of the help message is gone. *That*
is real 'broken'.
Quirky: Windows uses cntl-C to copy selected text to the clipboard and
(where appropriate) cntl-V to insert clipboard text at the cursor pretty
(Anti-maintained: I think Microsoft wants people to abandon unix-like
command processing and that they are intentionally keeping CP ugly and
Now lets look at IDLE: Standard black (+ other colors) on white and
close to standard gui. *Much* prettier than CP 'Unlimited' lines of code
and output in windows. *Much* more functional in this respect. I cannot
think of *anything* in IDLE that compares to the brokeness of CP in
throwing output away. Standard ^C,^V behavior. To me, IDLE is much less
quirky than CP.
Oh, but it did have one quirk -- the right context menus lacked the
standard Copy and Paste entries of Windows applications. When that was
added for all versions, a couple of people challenged it as a
default-only 'enhancement' rather than all-versions 'bugfix'. That
challenge directly lead to PEP434. In last two months since, IDLE work
has mostly stopped. I will say more about maintenance problems, but
getting back to CP versus IDLE...
Impressed? You should be. Open Start menu / Python33 / Python (command
line) and both of those result (modulo the specific character) in
UnicodeEncodeError: 'charmap' codec can't encode character
'\xc8' in position 0: character maps to <undefined>
and we have not even gotten beyond latin-1, into the 'real' unicode char
set, which IDLE supports MUCH better. For display, default United States
CP is close to ascii-only.
In summary: IDLE makes Python interactive mode tolerable and useful on
Windows in ways where CP completely fails. If you are worried about
something making Python look bad on Windows, target CP before IDLE.
> Getting things committed in Python is not easy, and even if we get a
> sudden influx of good patches (which I doubt)
Given recent history, this is silly. A year and a few months ago, (Dec
2011, I think), I asked Roger Serwy to start submitting patches, with
the promise to review and possibly commit some. Consequently, in the
last year, we have *already* gotten a 'sudden influx of good patches'.
It is true that I have not yet kept up my end of the bargain. One
problem for me has been an inability to test IDLE patches on Windows
with repository builds, due to the need for a working tkinter. It turns
out that the pc build files are buggy and the devguide and the (to me
confusing) pcbuild/readme do not have the workaround that was
communicated to me only about 10 days ago.
> these will take time to review and get committed.
In spite of my slowness, others have been active. Searching
cpython/Misc/NEWS for ' IDLE ' (case-insensitive) returns 31 hits. For 4
months (Oct-Jan), that is pretty active, certainly much more active than
in the years prior to 2012. As soon as PEP434 is resolved and Roger is
fully on board, the pace will pick up again.
At least a few people have been given commit privileges but never (or
essentially never) exercised them. I think a couple were specifically
for working on IDLE. I have not asked any of these people why, but I can
imagine from my own experience that uncertainty over what is and is not
allowed is one reason.
I will discuss repository separation in another response, but request
here that the still vague idea of doing something in the *future* not be
used to stop PEP434, in whatever form, and current IDLE development *now*.
Terry Jan Reedy
More information about the Python-Dev