REPL: Prompt obscures chars for print with end=","

Documentation

(A clear and concise description of the issue.)
Learning python for the first time. Got to section 3.2 on the tutorial.pdf document.

First while loop, with Fibonacci, in section, no problem. Works the same.

However, when I get to the last while loop for Fibonacci, I get a different result.

The output in the document shows: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987,

However, my output is: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987,

Inclusion of end somehow removed the first 0, 1. Not sure why. Tutorial and console is 3.13.3.

I'll provide screenshots later tonight (if needed).

Any help figuring out why is welcomed. And yes, I did double check the syntax was correct.

I've checked and the docs are correct, you may have mistyped or forgotten a line.

Double check your initial values of a and b -- make sure you called a, b = 0, 1 at the start.

Your output is consistent with starting with a, b = 1, 2 instead.

Please open a topic in the help forum to ask further questions about this:

https://discuss.python.org/c/help/7

*sigh* Clearly you didn't read my last statement in that I have retyped the example multiple times. I looked for ANY misplaced commas or anything and found nothing. And no I DIDN'T put a, b = 1, 2. I am using 0, 1. I'll include screenshots when I get home from work in ~6 hours.

…

On Fri, Jul 11, 2025, 10:13 AM Hugo van Kemenade ***@***.***> wrote: *hugovk* left a comment (python/cpython#136553) <#136553 (comment)> I've checked and the docs are correct, you may have mistyped or forgotten a line. Double check your initial values of a and b -- make sure you called a, b = 0, 1 at the start. Your output is consistent with starting with a, b = 1, 2 instead. Please open a topic in the help forum to ask further questions about this: https://discuss.python.org/c/help/7 — Reply to this email directly, view it on GitHub <#136553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALVXZP6YV3FTFIEAU2GT7D3H7WDBAVCNFSM6AAAAACBKKMCFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRTGEYDENBZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

I also see the documented output when running the example. It could be possible that your terminal is swallowing the first two values for some reason.

Got to section 3.2 on the tutorial.pdf document.

PDF? I'm not sure we even ship PDFs of the docs. I guess there's a chance the example is wrong if you got it from a third-party. What happens when you run the example from the official docs?

PDFs are here: https://docs.python.org/3/download.html

TIL!

Here is the screenshot as promised

If you need tablet specs, os specs, etc, let me know.

Looks like your terminal is having issues with the output not ending in a newline, and is printing the next prompt on top of the output. The four characters of the prompt (>>> ) are covering the first four characters of the output (0,1,). Usually, the prompt should be printed after the output, like this:

>>> a, b = 0, 1
... while a < 1000:
...     print(a, end=',')
...     a, b = b, a+b
...     
0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,>>>

Sharing details about your terminal / environment would probably be helpful to confirm whether this is an issue with your terminal or with CPython.

As a workaround, you can try adding a call to print() immediately after the while loop to force the prompt onto the next line.

Hey Brian, About: Windows Terminal, Version: 1.22.11141.0 OS: Windows 11 Home, Version: 24H2, OS build: 26100.4652 Processor: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz Tablet: Surface Pro 8 Would you like any other information? And you are correct that the prompt is covering the values. The added print() did show the missing numbers. But it is interesting... Let me know if you need anything more.

…

On Fri, Jul 11, 2025 at 5:11 PM Brian Schubert ***@***.***> wrote: *brianschubert* left a comment (python/cpython#136553) <#136553 (comment)> Looks like your terminal is having issues with the output not ending in a newline, and is printing the next prompt on top of the output. The four characters of the prompt (>>> ) are covering the first four characters of the output (0,1,). Usually, the prompt should be printed after the output, like this: >>> a, b = 0, 1 ... while a < 1000: ... print(a, end=',') ... a, b = b, a+b ... 0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,>>> Sharing details about your terminal / environment would probably be helpful to confirm whether this is an issue with your terminal or with CPython. As a workaround, you can try adding a call to print() immediately after the while loop to force the prompt onto the next line. — Reply to this email directly, view it on GitHub <#136553 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALVXZL5JCQ7ZAVZZTFS53T3IBHEVAVCNFSM6AAAAACBKKMCFKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANRUGM2DMMZXGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

This is a duplicate of at least one issue which must also have been closed without doing anything. For Python as default installed or compiled on Windows, the output for this example is wrong and should be fixed. Either add

else:
    print()

to the while statement to print a final newline, which would be the proper thing to do in practice, or also give the Windows output.

The bug only exists in interactive shells in windows. This is how it works on my linux machine:

And in the window case, if we use a print() at the end we can avoid this:

I suggest to add the change in docs. This will cause some confusion IMO. (I think testing example case in windows interactive shells is pretty common) OR specify the unintended case in windows.

@zooba

We could update the example, but ideally Windows shouldn't be overwriting those first few characters in the first place. Is there any way to prevent it from doing that? (cc @zooba @chris-eibl)

We could update the example, but ideally Windows shouldn't be overwriting those first few characters in the first place.

Maybe we can solve this in separate PRs? I will create a PR for doc fix later since it's easy to do. IMO it's better to specify the bug case in windows in doc.

This is a duplicate of #128067.

We could update the example, but ideally Windows shouldn't be overwriting those first few characters in the first place. Is there any way to prevent it from doing that? (cc @zooba @chris-eibl)

This is definitely a bug of the new REPL on Windows. I can reproduce it for 3.13 and 3.14 in both a legacy and the new windows terminal. Setting the environment variable PYTHON_BASIC_REPL=1 before invoking python.exe switches back to the old REPL, which doesn't exhibit this bug on Windows.

See the linked issue above which has links to even more duplicates.

I did not realize before that this is new. A loop is not needed to reproduce. In 3.8, for instance:

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

Currently, >>> covers 1,.

Navigation Menu

Repository navigation

REPL: Prompt obscures chars for print with end="," #136553

Documentation

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

REPL: Prompt obscures chars for print with end="," #136553

Description

Documentation

Activity

hugovk commented on Jul 11, 2025

novocode commented on Jul 11, 2025

ZeroIntensity commented on Jul 11, 2025

hugovk commented on Jul 11, 2025

ZeroIntensity commented on Jul 11, 2025

novocode commented on Jul 11, 2025

brianschubert commented on Jul 12, 2025

novocode commented on Jul 12, 2025

terryjreedy commented on Jul 12, 2025

LamentXU123 commented on Jul 12, 2025

ZeroIntensity commented on Jul 12, 2025

LamentXU123 commented on Jul 12, 2025

picnixz commented on Jul 12, 2025

chris-eibl commented on Jul 12, 2025

terryjreedy commented on Jul 13, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions