[Python-Dev] IDLE in the stdlib (original) (raw)

Terry Reedy 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 that.

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 much everywhere.

(Anti-maintained: I think Microsoft wants people to abandon unix-like command processing and that they are intentionally keeping CP ugly and disfunctional.)

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...

From IDLE:

print('\x80') € print('\xc8') È

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

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 mailing list