Skip to content

[Windows] Python 3.13 New REPL prompt swallows characters with print(..., end=" ") #128067

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

Open
cessor opened this issue Dec 18, 2024 · 3 comments
Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes OS-windows stdlib Python modules in the Lib dir topic-repl Related to the interactive shell type-bug An unexpected behavior, bug, or error

Comments

@cessor
Copy link

cessor commented Dec 18, 2024

Bug report

Bug description:

I encountered the following unexpected behavior when working with the new REPL on Windows 10's cmd just now:

Actual Behavior

>>> for i in range(0, 14, 2):
...     print(i, end=" ")
...
>>> 4 6 8 10 12
  • When I use print and pass an argument to the end-parameter, the resulting line is missing 4 characters.
  • The four chars of the REPL prompt >>> appear to write over the line, as the cursor blinks on the first visible position (indicator sits under the number 4)
  • Typing overwrites the shown chars.

Expected Behavior

>>> for i in range(0, 14, 2):
...     print(i, end=" ")
...
0 2 4 6 8 10 12 >>> _
  • REPL on Python 3.12 works as expected.
  • Results are printed in one line, prompt appears at the end, cursor follows at end of line.

Note:

This works as expected:

>>> for i in range(0, 14, 2):
...     print(i)
...
0
2
4
6
8
10
12

CPython versions tested on:

3.13

Operating systems tested on:

Windows

Linked PRs

@cessor cessor added the type-bug An unexpected behavior, bug, or error label Dec 18, 2024
@ZeroIntensity ZeroIntensity added the topic-repl Related to the interactive shell label Dec 18, 2024
@picnixz picnixz added stdlib Python modules in the Lib dir 3.13 bugs and security fixes 3.14 new features, bugs and security fixes labels Dec 20, 2024
@devdanzin
Copy link
Contributor

Confirmed on main:

>>> print(10, end=' ')
>>>

It's possible to see the 10 output appear then be overwritten by the prompt. Any string ending without a newline seems to suffer from this:

>>> print("a\n", 10, end=' ')
a

@devdanzin
Copy link
Contributor

devdanzin commented Dec 24, 2024

It's possible to capture output in a StringIO in code.InteractiveInterpreter.runcode and add a \n character if the output doesn't end in a newline. It should change the behavior to (in both Windows and Linux):

>>> for i in range(0, 14, 2):
...     print(i, end=" ")
...
0 2 4 6 8 10 12 
>>> _

That is, the prompt would always appear on a new line.

If this is considered a good solution, I can submit a PR.

Edit: with a PoC change, the issue is resolved and test_pyrepl, test_repl and test_code pass.

@devdanzin
Copy link
Contributor

The proposed fix changes two behaviors that could be considered bugs in how output is handled.

Without the change, in Windows, printing a very long line ending with a space would result in its last wrapped line being overwritten by the prompt and further input:

>>> print("abcdef" * 30, end=' ')
abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef
>>> efabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef

While on Linux, without the change, the prompt appears right at the end of the long line:

>>> print("abcdef" * 30, end=' ')
abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef
abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef >>>

With the change, the prompt always appears on a new line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes 3.14 new features, bugs and security fixes OS-windows stdlib Python modules in the Lib dir topic-repl Related to the interactive shell type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants