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

[cessor]

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

• gh-128067: Add newline to new REPL output when needed to avoid chopping characters #131011
• gh-128067: Fix pyrepl overriding printed output without newlines #138732

[devdanzin]

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]

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]

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.