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
'3' and a new prompt. In IDLE, the pasted \n is ignored and a typed \n
is required to trigger execution. As a consequence, pasting multiple
statements does not work; anything after the first is ignored.

If this cannot be changed, following
Paste -- Insert system-wide clipboard into window
with (The shell will only recognize one statement)
would at least document the limitation.

This seems to be problematic in general. I have worked on a patch now,
but it fails to succeed while pasting multiple lines. The problem is
that when a second line is pasted, IDLE is still marked as "executing"
so it ends up just pasting the line without executing it.

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:

• More intuitive to users that have never pasted multiple lines into a shell terminal.
• More sensible: why should Pasting execute anything?!
• Allows editing any of the statements before running.
• Keeps all statements together for Alt+P recalling.

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.