-
-
Notifications
You must be signed in to change notification settings - Fork 30k
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: Pasted newline doesn't trigger execution when typed newline would #47809
Comments
Winxp, 3.0b2, but I suspect earlier as well, since reported on c.l.p. If I paste '1+2\n' into the command window interpreter, it responds with If this cannot be changed, following |
This seems to be problematic in general. I have worked on a patch now, |
There are 2 issues here: (1) There should be a quick & obvious way to paste and run several statements. (2) If a user types several statements and presses Enter, all should run. The current behavior is badly broken, and pasting is just one of the ways to trigger this. Splitting this into a new bug: http://bugs.python.org/issue9618 The original formulation of this bug seems to favor an xterm-like solution to (1): when you paste \n-terminated, run them immediately, as if each \n was an Enter press. I think a more IDLEic [think "idillic" ;-)] approach to solving (1) is to solve (2): keep the behavior that pasting creates a multi-line block without executing anything, make Enter execute it all. Benefits:
If there is agreement on this, then this issue requires no action beyond solving bpo-9618. |
I switched to patch review because I am not sure unit test is possible. I did not advocate a change to immediate execution in my original post. I noted that pasting multiple statements does not work and that if it cannot be made to work, the limitation should be documented. I am fine with pasting working the same as when one copies a previous statement to the current input prompt with <cursor on line>+Enter. Issue bpo-9618 elaborated "<statement>\n<statement> does not work" by pointing out that <simple statement>\n<simplestatement> silently ignores the second while <compoundstatement>\n<simplestatement> is reported as a syntax error. I pointed out that if <compoundstatement> does not end in \n, it really is a syntax errror for interactive mode, but even with \n\n, it still is reported as such when it is not. So a possible revised minimal request is that an initial compound statement be executed and the rest ignored. However .... I have discover that the elaboration is not exactly true either. msg114019 says "If you manage to type several simple statements into the prompt (by copy-pasting them, using Ctrl+J, or creative deletion), IDLE runs the first one and silently ignores the rest:" However, when I edit 'for x in []:' to 'x = 3' *after* adding ' y = 7' I get with 3.1:
>>> x
2
>>> y
4
>>> x = 3
y = 7
>>> x
3
>>> 7
7
Somehow, both statements are executed because of the indent! This might be considered a bug as the indent should be a syntax error. Without it, the second line is ignored, as reported. The significant difference between the (Windows) interactive interpreter and IDLE is that the II is *line* oriented* while IDLE is *statement* oriented. With II, entry (and history) is by single lines. A line entered cannot be edited and history (up/down arrow) copies a single previous line. Multiline compound statements require *manual* indentation. Rerunning (and editing) a multiline compound statement requires rerunning (and editing) each line one at a time. IDLE, allows multiline editing before the double Enter (hence the shenanigans above, impossible with II), does auto indents, and retrieves and allows editing of entire multiline statements with <cursor>+Enter. Since the IDLE Shell operates differently from the II, it cannot and should not imitate II paste behavior. It seems to treat pasted code more-or-less the same as edited code from the keyboard, which it expects to be a statement, single-line multi-statment, or compound statement. If there is a problem, I think perhaps it is in how it handles abusively edited multiline statements. Perhaps it should always raise SyntaxError instead of silently ignoring part of the entry. |
Re: testability, Tarek has written tests for distutils interactive commands by monkey-patching input/raw_input. A bit ugly, but gets the job done. |
Could we borrow code from the ipython %paste command? This issue is also referenced from bpo-5124. |
The core problem is that IDLE only executes the shell buffer when the <<newline-and-indent>> virtual event gets sent by physically pressing the Enter key. Pasting the clipboard contents with \n will not trigger the enter_callback function in Lib/idlelib/PyShell.py. The MultiLineRun.py extension as part of IdleX intercepts the pasted text and splits the buffer on '\n' and then runs each line. Mark, what you are suggesting is adding something like a "Paste and Execute" option for the shell and its right-click menu which mimics the %paste magic from IPython. That's doable. |
In bpo-9618, it was pointed out that IDLE Shell inherits from code.InteractiveConsole, and that #51989 proposes to allow multiple statements there. In 3.5, this example from msg114561 now gives a SyntaxError, as it should. >>> x = 3
y = 7 Seven years after opening this, I am more appreciative of 'enter and execute (and recall)' one statement at a time, especially for beginners. Ditto for being able to edit a paste before executing. So I am more inclined to just add the note to the doc (which currently says nothing about executing anyway). Someone who wants to paste, execute, and recall multiple statements as a block, without having output interleaved, can wrap with 'if 1:'. >>> if 1:
1+2
3+4
3
7 |
ppperry, your title revision was wrong. Multiple line statements are pasted just fine, like single line statements. My original title was correct and the new one better exposes the essential point of this issue by elaborating 'not same as'. |
My initial experiments indicate that pasted tabs are at least sometimes treated differently, but I need to do more to be sure. |
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: