GeezerVison is showing github.com — Strip `>>>` and `...` when pasting to REPL · Issue #157612 · python/cpython
Strip >>> and ... when pasting to REPL #157612DescriptionFeature or enhancement
Proposal:
I often find myself wanting to paste some REPL code straight into the REPL, but both >>> and ... are preserved, and I have to manually cut those.
Let's consider stripping these automatically omitting the outputs, if the current prompt is empty.
E.g.
I copy this text:
>>> class A(object):
... def __new__(self):
... raise TypeError('i do not exist')
...
>>> class B(A):
... __new__ = object.__new__
... def __init__(self, x):
... self.x = x
...
>>> B(1)In the REPL, I'm not inside a string or anything:
I paste the text:
>>> class A(object):
... def __new__(self):
... raise TypeError('i do not exist')
...
... class B(A):
... __new__ = object.__new__
... def __init__(self, x):
... self.x = x
...
... B(1)Now I can edit it and run it.
This feature is a UX convenience and rough edges are expected:
>>> and ... are conventional prompt strings that I think are fine to hardcode (practicality beats purity)- lines from stdout starting with
>>> or ... will be detected as REPL lines, but I don't think it's a problem at all
- there are slight semantic differences around
sys.displayhook and builtins._
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response
Linked PRs
Reacted by trag1c, Oskar Skog, An Long, Eduardo Villalpando Mello, Maxim Martynov and Sergey B Kirpichev Reacted by Abduaziz Activityskirpichev commented on Sep 16, 2026
>>> and ... are conventional prompt strings that I think are fine to hardcode (practicality beats purity)
Though, remember that sys.ps1/2 are configurable, and e.g., pypy uses different ps1 per default. IPython has another popular style of prompts. Maybe this is something, that must be customizable like sys.displayhook and so on. We shouldn't hardcode such stuff. Above proposal looks as a sane default, of course.
Note also, that IPython implements that differently: prompts are not stripped out, just ignored. Maybe this is better. I find this certainly better for IPython, because one has meaningful prompts per default (numbered input/output). But I would expect this harder to implement (syntax coloring, nested prompts, etc). johnslavik commented on Sep 17, 2026
Though, remember that sys.ps1/2 are configurable, and e.g., pypy uses different ps1 per default. IPython has another popular style of prompts.
I discussed this in some depth in the PR and I think it can only complicate this small UX improvement for now.
I still believe it's perfectly fine to hardcode >>> and ... as the only prompt strings matched in this dead simple feature for now.
If people really need sth more sophisticated, I say: let's hear them ask for it first and iterate later on. If anything, you can always edit what you paste, like you used to. It's not a big deal, really.
Do you personally use a different prompt string and would find it critical for this small feature? skirpichev commented on Sep 17, 2026
If people really need sth more sophisticated
I doubt this will really complicate things. What you are trying to do here looks like an example of IPython's input transformers.
Do you personally use a different prompt string and would find it critical for this small feature?
Well, for most of my Python repl sessions I still use IPython :-) Default sys.ps1/2 are reasons to avoid builtin repl for long sessions.
I would appreciate if new repl will be more customizable. hugovk commented on Sep 17, 2026 I think the main use case for this is copying and pasting code from webpages, which nearly always use the default >>> and ....
I don't think we need to complicate it to cover custom prompts, at least not to begin with. Reacted by Sergey B Kirpichev, Bartosz Sławecki, David Lord, Nikita Karamov and Tan Long treyhunner commented on Sep 17, 2026
I think the main use case for this is copying and pasting code from webpages, which nearly always use the default >>> and ....
Copying from webpages is exactly what I thought of when reading this issue.
I like this idea, in theory at least. It's definitely something I've run into, to the point where I've copy-pasted REPL output into a text editor and deleted the first 4 characters from each line, deleted output lines, and then copy-pasted again from the editor into an actual REPL.
This is less of an issue than it used to be because so many webpages now include CSS to customize what is selectable/copyable. It is still an issue though.
I like that output lines would be omitted by the current PR.
I do wonder whether that could cause an issue by stripping non-output text somehow, but I can't think of an obvious scenario where it might.
Slightly related to this issue: I've often wished for the opposite of this feature (copy-pasting from the REPL without copying the prompts or output). The new history mode (F2) sort of accomplishes that, but a bit awkwardly. Reacted by Bartosz Sławecki and Tan Long skirpichev commented on Sep 17, 2026
I don't think we need to complicate it to cover custom prompts, at least not to begin with.
Yes, proposal looks now solid for me.
Yet, I think it does make sense to think about more generic cases. This feature implemented differently wrt the IPython. I believe it will block us from supporting in the new repl something like IPython input transformers. Is this ok?
In short: should we preserve original text (IPython) or save it's transformed form (current patch)?
I like that output lines would be omitted by the current PR.
Yes, it looks attractive for this feature. But if you consider more generic input transformations (e.g. if you would like to strip out IPython-like sys.ps1/2) - maybe it's not.
I've often wished for the opposite of this feature (copy-pasting from the REPL without copying the prompts or output).
Please don't turn this on by default. I believe a lot of people copy-pasting from the REPL to provide repl examples in webpages, doctests, etc. johnslavik commented on Sep 18, 2026
Please don't turn this on by default. I believe a lot of people copy-pasting from the REPL to provide repl examples in webpages, doctests, etc.
+1, if the proposed feature lands we won't really need this right? :) skirpichev commented on Sep 18, 2026
if the proposed feature lands we won't really need this right? :)
No, sometimes it's useful. I typically use repl to prototype Python code, and at some point - just copy cell content (or it's part) to file. johnslavik commented on Oct 15, 2026 Since I posted this, I found myself in 2-3 situations where this feature would have been useful.
One was when I wanted my students to play around with things in the REPL, and I wanted to send them a copy of the output from my REPL. (Sure -i would have worked too, but copy-paste from REPL is faster).
Second was when I was presenting my students an algorithm with different parameters on LHS and RHS and wanted them to spot the pattern by comparing my 2 REPLs. I had to copy from the first REPL to the second.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|