New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLE - deprecate running without a subprocess #60327
Comments
Removing the option of running IDLE without a subprocess would simplify the maintenance of IDLE. This should be deprecated for 3.4 and then fully removed in 3.5. Here's a link to a brief discussion on IDLE-dev: http://mail.python.org/pipermail/idle-dev/2012-June/003124.html Attached is an initial patch to issue a deprecation message. |
Make it pop up a dialog with the message too in the patch, please. |
A popup menu on every invocation of IDLE would be a very user-unfriendly thing to do. If it's possible that a print to stderr might not be visible to a user, another solution might be to use the approach in Lib/idlelib/macosxSupport.py tkVersionWarning which causes the warning message to show up in the PyShell window. |
I agree that a message within the shell would be more informative to the user. The _rev1 patch also adds a message to the shell. |
Looks good for me. |
New changeset 0430986a8c03 by Andrew Svetlov in branch 'default': |
Change priority to deferred blocker for reminding to remove no-subprocess mode in 3.5. Thanks, Roger. |
Hi, I just found a use for this feature, with --
|
Campbell, your example runs IDLE *with* a subprocess. The "use_subprocess" flag defaults to True. |
@Roger, I should have mentioned I had to add "-n" to the argv so subprocess would be disabled. |
I think that usage is not officially supported, so we cannot grant this way will work forever. |
FWIW, I help a lot of people with IDLE problems and sometimes the -n option is the only thing that saves them. ISTM that removing it is not such as a good idea. |
@Raymond: What is so broken about IDLE that requires using "-n" to fix it? Let's try to fix those problems rather than keeping up the maintenance burden of supporting two execution modes. |
The issue is usually with firewalls, security software, socket issues, etc. While the root problem lies outside IDLE, often the simplest way to get someone up and running is to use the -n option. This is one of many annoyances that arise when teaching students Python using IDLE:
* Preferences window crashing
* Default font-size on a retina mac is tiny
* Inability to shutoff the prominent warning messages
* Control-A goes to the beginning of the line, past the >>> prompt.
* On Windows, IDLE sometimes has a two second delay before it runs scripts
* Students find that IDLE mysteriously pastes a clipboard into the interactive prompt unintentionally
* It is a common complaint that IDLE hangs
* Getting the correct Tcl/Tk setup on Macs is problematic.
* Starting IDLE from the command line emits messages about "setCanCycle is deprecated" |
On 22 February 2013 22:56, Raymond Hettinger <report@bugs.python.org> wrote:
Not experienced any of the problems on Linux. |
Roger has submitted patches for some of the items on your list (off topic for this issue), especially crashes and stalls. Some still need review and commits. Mac tends to be the most difficult platform to get tests on. While these would be better discussed on other issues or on idle-sig (mirrored on gmane), I will briefly comment on a few. Cntl-A selects the entire window on Windows, while Home sends the cursor to the beginning of the line. On the current command line, it first goes after the prompt, and alternates before and after with repetition. This is kbk's design. On old command lines, it only goes before, and that is a bug to be fixed. I think there is an issue, but cannot find it. I have never seen unprovoked pasting, nor an unexpected startup delay when running from the editor. I cannot find 'setCanCycle' in 2.7 or 3.3 Lib/idlelib/*.py and 'deprecated' only appears once, in a comment. I expanded the 'setCanCycle' to the entire cpython repository and still did not find it, so that is a complete mystery. |
Surely nowadays there are better ways than sockets to communicate between processes? Pipes? |
Slight correction: While I do not believe I have seen *clipboard* contents pasted, after running a program from the editor that prints (to the shell), I *have* seen the last line reprinted when trying to enter something new as the prompt. This sometimes might look like pasting from the clipboard. I sometimes have to hit enter a couple of times and ignore the SyntaxError to get a clean prompt. I have no idea if this is exclusive to running in a subprocess; it should be fixed independently of this issue. The idea of using pipes is being explored on Idle-sig. |
I opened bpo-18823 "Idle: use pipes instead of sockets to talk with user subprocess" I think this or a socket fix is needed before we remove -n. |
If the 3.4 changes are done, can we either close this or remove 3.4 from the versions? |
Every enhancement issue can be bumped to 3.5. |
It would be nice if we are able to to this in 3.5, because the dependecy is accomplished, but not doing so is not a release blocker. |
I frequently use IDLE as an interactive shell to Python with the Editor attached. It's very nice for this purpose as it's lightweight and embedded in Python delivery. This is only possible with -n flag as without it each press on F5 will restart the interpreter and I lose all variables, graphs etc. Under 2.7 (not related to this thread) I'm also unable to use interactive graphs [ ion()] in matplotlib without the -n flag. Is there another way to run the module without restarting interpreter without the -n option? Will 2.7 be affected by this change in the future? |
Torgil, thank you for the interesting feedback. I will respond to your four paragraphs slightly out of order.
If you want to pursue this, please open a new issue on the tracker or post to the idle-sig list or its news.gmane.org mirror gmane.comp.python.idle. In either case, say more about what 'not work' means. 4.This issue was opened before PEP-434 and before 2.7 maintenance was extended from 5 years (expiring now as 3.5 is released) to 10 years. Hence the deprecation notice was not added to 2.7. I do not expect this to change. |
I have some different ideas for this issue that would not necessarily involve removing -n. While -n is can be an inferior experience for users (user code blocks the GUI, other interference, especially tkinter), the reason given for deprecation is to simplify IDLE maintenance by eliminating alternate code paths. Summary: a new rpc_local module might allow us to simplify code now, without removing -n, and provide a path to switching subprocess communication from sockets to pipes.
|
Deprecation has been done and a message is printed under the splash screen. With 5 more years of maintenance experience under deprecation, I have not experienced -n mode as a maintenance burden. So I have no inclination at present to remove it (or even implement any of the ideas above). Deprecation usually means 'no maintenance'. For idlelib, that means no new tests specifically for -n mode (and there never were any). I don't do manual tests either. (More patches and more testing in regular mode is more important to me.) It is possible that some feature has been disabled in that mode, but there are no such reports and I have not encountered anything in my occasional experiments in that mode. (Such as when someone claim that something only worked with -n.) I have occasionally touched blocks with 'if subprocess ... else ...' but it has not been hard to leave the else part alone. A year or so ago, I added a 'Startup failure' section to the IDLE doc. It list multiple possible causes and things to try. -n is irrelevant to most of them. If someone knows of another current issue, open a new tracker issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: