This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Pasting multiple lines in the REPL is broken since 3.9
Type: behavior Stage: resolved
Components: IO Versions: Python 3.9
process
Status: closed Resolution: third party
Dependencies: Superseder:
Assigned To: Nosy List: ned.deily, romainfv, terry.reedy
Priority: normal Keywords:

Created on 2021-03-02 21:45 by romainfv, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Messages (6)
msg387976 - (view) Author: Romain Vincent (romainfv) Date: 2021-03-02 21:45
DISCLAIMER: This is the first time I submit an issue here. In advance, my humble apologies if I missed something.
Feel free to correct me :)

--

I regularly test snippets of code by pasting them from a code editor to a shell REPL.

It works perfectly well in python 3.8 or 3.7 but not in python 3.9.

Demonstration:

Try to copy and paste the following simple snippet:

---

def f():
    print("hello world")

---

The result in a python 3.8 REPL (same with 3.7):

---

$ python3.8
Python 3.8.6 (default, Nov 20 2020, 18:29:40)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
    print("hello world")
>>> f()
hello world

---

But with python 3.9:

---

$ python3.9
Python 3.9.1 (default, Dec 10 2020, 10:36:35)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
    print("hello world")
  File "<stdin>", line 1

    ^
SyntaxError: multiple statements found while compiling a single statement

---

This behavior happens with any snippet of code containing at least one indented line, whether by tabs or spaces and whatever the number of spaces.


Regards.
msg388071 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2021-03-04 03:08
Sorry, I cannot reproduce that behavior. The output you show isn't what I would expect, in any case.

$ python3.8
Python 3.8.7 (v3.8.7:6503f05dd5, Dec 21 2020, 12:45:15)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
...     print("hello world")
...
>>> ^D
$ python3.9
Python 3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01)
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def f():
...     print("hello world")
...
>>> ^D

Note the missing '...' continuation prompts.  So can you verify that the text when you paste it includes just a standard linefeed (LF) control character as the end-of-line delimiter?  Other possible differences might be whether the python in use was linked with the BSD libedit library or with GNU readline but that shouldn't make a difference unless you have some non-default options in their configuration files.  You can check which one is in use with this:

$ python3.8 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using GNU readline.
$ python3.9 -c "import readline;print(readline.__doc__)"
Importing this module enables command line editing using libedit readline.

If all else fails, from where did you obtain the pythons that you are using?  And in what environment are you running those commands, i.e. the macOS Terminal.app?
msg388179 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2021-03-06 01:02
On both Windows and macOS Mohave with both 3.9 and 3.10 I get normal behavior.

If it were not for the $ python3.x line, the missing '... ' in Romain's output would have suggested that he was using IDLE.  But IDLE should accept pasted ascii statements just fine.
msg388248 - (view) Author: Romain Vincent (romainfv) Date: 2021-03-07 19:49
The lack of dots was something I noticed.

So from your questions (Ned Deily) I have been testing out several things and found a "wae"!

But first, to answer your questions:

1. both LF and CRLF and it didn't change anything.

2. Running "import readline;print(readline.__doc__)" prints
"... GNU readline", with python 3.7, 3.8 and 3.9.

3. I am using iTerm2, but the problem also happens on MacOS's native Terminal.app. Versions of python were installed with **homebrew**.


Maybe worth to mention: if I paste my code in a multi line string to execute with python -c, then it works properly.

e.g.

---

python3.9 -i -c 'a = 42
if a:
  print("hello world")
'
hello world
>>>

---

The example is different because I realized I had the same problem on python3.7 and python3.8 when the 2 first lines were at the same level of indentation (Note sure if this gives a hint as to what the problem is).



HOWEVER, if I use python versions directly downloaded from https://www.python.org/, then I don't have the problem at all!

Demonstration:

---
/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7
Python 3.7.2 (v3.7.2:9a3ffc0492, Dec 24 2018, 02:44:43) 
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline;print(readline.__doc__)
Importing this module enables command line editing using libedit readline.
>>> a = 42
>>> if a:
...   print("hello world")
... 
hello world
>>> 

---

Same for python3.9
msg388251 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2021-03-07 22:57
Thank you for retesting with the python.org installer.  Since this is Homebrew specific, please open an issue with them, with the updated debug information.
msg388254 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2021-03-07 23:44
It certainly could be an issue with using GNU readline vs libedit and Terry is correct that you should follow up with Homebrew. But I don't think you stated from which code editor application you were copying from; that could also make a difference. In any case, good luck!
History
Date User Action Args
2022-04-11 14:59:42adminsetgithub: 87545
2021-03-07 23:44:45ned.deilysetmessages: + msg388254
2021-03-07 22:57:20terry.reedysetstatus: open -> closed
resolution: third party
messages: + msg388251

stage: resolved
2021-03-07 19:49:56romainfvsetmessages: + msg388248
2021-03-06 01:02:47terry.reedysetnosy: + terry.reedy
messages: + msg388179
2021-03-04 03:08:58ned.deilysetnosy: + ned.deily
messages: + msg388071
2021-03-02 21:45:36romainfvcreate