GeezerVison

Documentation build overview

📚 cpython-previews | 🛠️ Build #35333880 | 📁 Comparing 80e8d4b against main (7f52444)

  🔍 Preview build  

We could, but I find that limiting this to >>> and ... only makes this feature simpler and easier to predict.

Do you personally customize your PS1 and would need that in this feature?

Not explicitly but it is documented behavior on the tutorial.
However, I was thinking more of tools/IDEs modifying PYTHONSTARTUP to alter the behavior of the REPL (VSCode does it -- although mostly to insert ANSI characters; but there could be other tools that do change it completely)

However, I was thinking more of tools/IDEs modifying PYTHONSTARTUP to alter the behavior of the REPL (VSCode does it -- although mostly to insert ANSI characters; but there could be other tools that do change it completely)

1. VS Code uses >>>. We already match >>>. Seems to me that matching against sys.ps1 doesn't solve anything here.

2. Your second suggestion would raise a TypeError under the VS Code terminal with patched sys.ps1¹, since VS Code sets sys.ps1 to a non-str object, which by the way floods the terminal, preventing the 3.15.rc2+ REPL from starting in the first place:

   Screen.Recording.2026-09-16.at.23.28.48.mov

   Consequently, your first suggestion would never match under the VS Code terminal with patched sys.ps1.

although mostly to insert ANSI characters

Would a user paste something that contains ANSI sequences?

I was thinking more of tools/IDEs modifying PYTHONSTARTUP to alter the behavior of the REPL

What tools or IDEs modify sys.ps1 to something other than >>>? How would following their specific behaviors benefit this feature in CPython?

Please also note that sys.ps1 can have leading lines which would make it more complicated to match. I'd really stick only with >>> and ... for now.

Oh you are right, didn't consider the case for it not being a string :)

There's a few edge cases here that I don't like around how the thing that actually executes is not the thing that the person pasting the snippet expects:

1. Copying between two new REPLs (the PR's stated use case) can silently change code. When an input line is wider than the terminal, pyrepl draws a \ in the last column and continues on a new row with no prompt. Raw pty bytes plus a real terminal emulator (WezTerm) confirm that terminals copy that row as a separate line. The PR drops the row, and the leftover \ joins the line onto the next statement. Most wrapped pastes end in a visible SyntaxError instead. The silent cases are mainly long list or string literals, which is arguably worse.

2. Lines abandoned with Ctrl-C get run. Both REPLs leave an abandoned line on screen with its prompt, followed by KeyboardInterrupt. The PR keeps the line and drops the KeyboardInterrupt as output, so code the user chose not to run now runs.

>>> x = 1
>>> x = 2
KeyboardInterrupt
>>> x
1

3. Replay stops at the first exception, and the traceback hides it. On Enter, pyrepl runs the whole buffer as one input and stops at the first statement that raises (Lib/_pyrepl/console.py). Many docs and tutorial sessions deliberately show an error and then continue. The printed traceback is the one the session already shows, so the skipped statements go unnoticed.

   • The PR's own test case (1 / 0, then print('hello')) never prints hello. The tests only
     check the edit buffer, never what runs.
   • In the tutorial dict session (datastructures.rst:576), the 8 statements after the KeyError are skipped and tel ends up wrong.
   • About 59 doc blocks have this shape.

4. The strip also runs at the (Pdb) prompt (a regression and outside the documented scope). PdbPyReplInput also sets more_lines, so the PR's more_lines is not None check doesn't exclude pdb. There's some plausible conflicts with the Pdb command grammar here:

   • q = …, quit = … or exit = … as the first statement quits pdb and ends the program. Under python -m pdb the process just exits with no confirmation.
   • run = … / restart = … restart the program with sys.argv set to ['=', …].
   • A one-line paste of >>> c continues the program.
   • Baseline gives a harmless *** SyntaxError.
   • pdb's command dispatch is old behaviour; the PR just makes a pasted session reach it.

There's more cases that are less concerning, but the state above makes me think that maybe this convenience is not worth it by default.

A plausible way out would be to discover the paste of a console session, and attach more info to the SyntaxError raised that would tell the user "To use Paste Mode (F3) to automatically strip >>> and ...". We would also need to address the backslash-wrapped lines handling, and at least document the exception handling difference.

1 - fixed, 2 - KeyboardInterrupt prompts are stripped out, 3 - implemented the new flow with error overlays, 4 - feature no longer works in pdb.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

✨ I have made the requested changes; please review again ✨

Thanks for making the requested changes!

@ambv: please review the changes made to this pull request.

Merging main to fix a flake.