Improving Idle (was Re: Python 3 ...)

[Terry Reedy]

On 7/19/2014 12:29 PM, Rick Johnson wrote:
> On Friday, July 18, 2014 8:21:36 PM UTC-5, Terry Reedy wrote:
>
>> What ancient version, or oddball system are you using? For
>> me, Win 7, both 2.7.8 and 3.4.1 "CONTROL+LEFT_ARROW" and
>> the cursor is before the 'a' of [>>> abc]. The HOME key
>> goes to the same place first, and they before >>> on the
>> second press (and before 'a' on the third).
>
> On versions 2.7.2 and 3.2.2

These are ancient versions from years ago that no one should be running 
Idle on now.  Before you say another word about Idle, and I mean this 
literally, update to current versions.  There have been about 80 issues 
fixed since 2.7.2 and well more than 100 patches pushed.

> CONTROL+LEFT_ARROW is landing *properly* in front of the prompt,

Re-read my comment that you quoted. This has been fixed.

> But my point is: We *MUST* remove this *excessive*
> indentation width from the IDLE shell!

To repeat: I agree, Raymond Hettigner agrees, everyone seems to agree, 
and we all have for years. http://bugs.python.org/issue7676 is over 4 
years old.  But a patch can only implement a specific new behavior, not 
just 'stop the old'.

>> I cannot connect [your complaint about IDLE hanging] to
>> behavior I have seen.
>
> IDLE will hang when editing Tkinter code. It seems to happen
> most often in two cases:

If you are running your tkinter code in the same process with Idle's 
tkinter code, either with ancient Idle or the '-n' startup option 
(possibly buried in a script), the situation is hopeless.

If you are running your code in a separate process (now the default), 
then, most likely, Idle is not hanging. It is just waiting for your hung 
process. If so, Shell / Restart shell (^F6) will end the user process 
and start a new one.

>    1. When running code that results in a Tkinter error.
 >
>    This can happen when mixing the "grid" and "pack" geometry
>    managers within the same "container" widget, which is a
>    Tkinter NO-NO, but it can also happen during other Tkinter
>    errors!

The user process might hang trying to display a message from *tk*, as 
oppose to Python code, including tkinter. If you start Idle in a console 
window with 'python -m idlelib' or in the console interpreter with 
'import idlelib.idle', you might see messages from tk, as I sometimes do 
(especially with a repository debug build).

>    2. During "quickly successive" back-to-back "run sessions"
>    of Tkinter GUI apps.
>
>    It seems that sometimes, if you don't give IDLE enough
>    time to release resources from the *LAST* run session, it
>    will freeze and then throw a "sub-process connection
>    failure" message, which, sometimes you can remedy by just
>    "trying again", but all to often you are forced to kill
>    the entire IDLE (and related sub-) processes.

Use one of the startup options directly above to see if you can get more 
information.  A repeatable or at least semi-repeatable failure case is 
needed to do anything.

> However, *EVEN* in the instances where a problem is a direct
> result of a "Tkinter NO-NO" (being witting or unwitting),
> the user of IDLE should *NEVER* be forced to kill processes

If you are talking about user processes, and we are talking about 
patching Idle, as opposed to Python or the OS (such as Windows), I 
disagree. If you are talking about the Idle process, then yes, I would 
prefer that once Idle starts, it run forever, and recover from any 
problems caused by users. Roger Serwy fixed many Idle shutdowns before 
being swallowed by a PhD program a year ago, but there is more to do.

>> I believe there is a proposal to be able to clear the
>> shell window. We just need to add "Clear and restart
>> shell". There is also an idea to put help output in an
>> output window. Undo-ing the result of hitting <enter>
>> seems like a sensible extension of undoing the
>
>> So sign the contributor agreement and volunteer to write
>> and review patches.

In particular, go to
https://www.python.org/psf/contrib
to read *about* the contributor agreement and then go to 
https://www.python.org/psf/contrib-form/
(when the page is working -- it is not at the moment) with Javascript 
turned on to submit on-line (or submit by old-fashioned s-mail). When 
the form is processed, the Contributor Form Received field of your user 
profile at http://bugs.python.org/user12501 will be updated.
Also, please update the email on that page to your current one.

We are much stricter about getting Contributor Agreements than we used 
to be. I will usually not look as non-trivial patches until the author 
has at least signed the agreement and will not commit until it is recorded.

> I would be willing to help *IF* i received more thoughtful and
> engaging replies like the type you always provide.

On the tracker at least, be polite and ignore impolite posts. I get them 
occasionally.

>      NOBODY IS GOING TO HELP WHEN THEY GET RESISTANCE!

PEP 434 negated some forms of Idle resistance.  However, it did not stop 
resistance in the form of criticism based on how Idle was (or might have 
been) years ago.

> I will visit the bug tracker again and see if i can provide
> some assistance there. Although, the last time i visited, i
> remember being annoyed by the tracker interface -- which i
> feel is overly noisy and far too complicated.

The tracker could stand improvement, and there is a meta-tracker for 
that, though not many devs work on it. There is an infrastructure 
committee working on overhauling the entire workflow process, not just 
the tracker. In the meanwhile, the tracker serves to keep track of issue 
and patches well enough to get some work done.

> All we need is
> a flat list of issues. Is there some method to export
> something more "readable"?

If you do a search, such as for open issues with component 'Idle', the 
results page has a button to download *all* the results, not just those 
displayed, as a .csv file.  Do whatever you want with that.

 > Or, some sort of documentation?

The Tracker Documentation link at the bottom of the left margin now goes 
to https://docs.python.org/devguide/triaging.html. Most of the page is 
only relevant when opening an issue or editing the headers. The last 
section is relevant for posting messages. How to upload a patch (the 
Browse button) is not described.

> I must admit, my excitement to help is usually depleted by
> the tracker interface before i even have a chance to offer
> anything substantial.

Buck up ;-)

> If this bug tracker does not improve, i will be forced to
> continue posting my grievances here.

As long as you base them on current Idle and are specific, that's fine. 
Patches you must upload yourself, for the responsibility trail.

-- 
Terry Jan Reedy