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 theSo sign the contributor agreement and volunteer to write and review patches.
In particular, go to https://www.python.org/psf/contribto 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 -- https://mail.python.org/mailman/listinfo/python-list
