[Python-Dev] IDLE in the stdlib

[Terry Reedy]

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