Improving Idle (was Re: Python 3 ...)
tjreedy at udel.edu
Sat Jul 19 22:45:07 CEST 2014
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
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
to read *about* the contributor agreement and then go to
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
> 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
More information about the Python-list