IDLE: Pasted newline doesn't trigger execution when typed newline would

@terryjreedy

BPO	3559
Nosy	@terryjreedy, @cben, @serwy, @merwok, @pppery
Files	fix_idleshell_paste.diff

^{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:

assignee = 'https://github.com/terryjreedy'
closed_at = None
created_at = <Date 2008-08-15.05:34:49.076>
labels = ['expert-IDLE', 'type-bug', '3.9', 'docs']
title = "IDLE: Pasted newline doesn't trigger execution when typed newline would"
updated_at = <Date 2019-09-20.21:07:15.690>
user = 'https://github.com/terryjreedy'

bugs.python.org fields:

activity = <Date 2019-09-20.21:07:15.690>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'IDLE']
creation = <Date 2008-08-15.05:34:49.076>
creator = 'terry.reedy'
dependencies = []
files = ['14618']
hgrepos = []
issue_num = 3559
keywords = ['patch']
message_count = 10.0
messages = ['71161', '91162', '114022', '114561', '114562', '189601', '189603', '254167', '254311', '270897']
nosy_count = 7.0
nosy_names = ['terry.reedy', 'cben', 'gpolo', 'roger.serwy', 'eric.araujo', 'THRlWiTi', 'ppperry']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue3559'
versions = ['Python 3.9']

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.

I cannot reproduce* any error with \n (It simply throws SyntaxErrors) and unable to find any issues with \t (Also throws SyntaxErrors) as was reported that they may exist.

Perhaps it should always raise SyntaxError instead of silently ignoring part of the entry.

I presume this was introduced at some point.

This should not be changed, why on earth would anyone want statements to execute on paste? It would be very inconvenient.

Do we still require a clarification in the docs? I doubt it is needed as this is the standard behavior for repl too.

*Tested on main branch and 3.13.

@StanFromIreland

No longer reproducible: as @StanFromIreland notes, pasted or typed input containing newlines now raises SyntaxError as expected, so there is nothing left to fix. Closing as out of date.

@serhiy-storchaka

@serhiy-storchaka (agent?) please close such issues as not planned, TiA.

Navigation Menu

IDLE: Pasted newline doesn't trigger execution when typed newline would #47809

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

IDLE: Pasted newline doesn't trigger execution when typed newline would #47809

Description

Activity

terryjreedy commented on Aug 15, 2008

gpolo commented on Aug 1, 2009

cben commented on Aug 15, 2010

terryjreedy commented on Aug 21, 2010

merwok commented on Aug 21, 2010

BreamoreBoy commented on May 19, 2013

serwy commented on May 19, 2013

terryjreedy commented on Nov 6, 2015

terryjreedy commented on Nov 7, 2015

terryjreedy commented on Jul 21, 2016

StanFromIreland commented on Feb 6, 2025

serhiy-storchaka commented on Jul 1, 2026

StanFromIreland commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions