gh-157612: Strip prompts and output from pasted REPL sessions

[johnslavik]

Copy a REPL example from a web page and paste it straight into the new REPL:

>>> def double(value):
...     return value * 2
...
>>> result = double(3)
>>> print(result)
6

At an empty >>> prompt, the REPL removes the copied prompts and output, leaving this code ready to edit:

def double(value):
    return value * 2

result = double(3)
print(result)

Indentation stays intact. Nothing runs on paste, so you can change double(3) to double(5) before running it.

This also makes it easier to send students examples or copy code between two REPLs to compare different parameters. You no longer need to delete prompts and output by hand.

The terminal must support bracketed paste, which tells the REPL where a paste starts and ends. The input must be empty, and the paste must start with a standard >>> prompt. Pasting into existing code, a string, or an input() prompt keeps the text unchanged.

Rough edges

As discussed in the issue, this only recognizes >>> and ..., since those are the prompts most web examples use. Output that looks like a prompted code line will also be kept as code.

The pasted code runs as one block, so it can behave differently from entering each command separately. The issue notes differences involving sys.displayhook and builtins._.

Tests cover prompt and output removal, different line endings, pastes that should stay unchanged, and editing before running.

• Issue: Strip >>> and ... when pasting to REPL #157612

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #35252870 | 📁 Comparing 132cd49 against main (7f52444)

  🔍 Preview build  

129 files changed · + 1 added · ± 128 modified

+ Added

• library/dialog.html

± Modified

• index.html
• license.html
• py-modindex.html
• _static/tachyon-example-heatmap.html
• builtins/functions.html
• builtins/stdtypes.html
• c-api/bytes.html
• c-api/capsule.html
• c-api/complex.html
• c-api/exceptions.html
• and 118 more...

[edvilme]

I think it should also consider cases in which the prompts have been changed. I think these would be few but still ?

E.g., (not endorsing changing the prompt, but something that could happen, especially in other tools modifying the REPL)

>>> import sys
>>> sys.ps1 = "py> "
py> # This is code I want to copy and paste later
py> class A(object):
...     def __new__(self):
...         raise TypeError("i do not exist")
...
py> class B(A):
...     __new__ = object.__new__
...     def __init__(self, x):
...         self.x = x
...
py> B(1)

[johnslavik]

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?

[edvilme]

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)

[johnslavik]

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?

Footnotes

1. Assuming the bug that follows (that prevents the REPL from starting in the first place) is fixed. ↩

[johnslavik]

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.

[edvilme]

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