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 issue 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 #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.