Repository navigation
Strip >>> and ... when pasting to REPL #157612
Description
Feature 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.displayhookandbuiltins._
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
Activity
Merge branch 'main' into pythongh-157612-strip-repl-prompts
skirpichev commentedon Sep 16, 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. 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 commentedon Sep 17, 2026
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 commentedon Sep 17, 2026
I doubt this will really complicate things. What you are trying to do here looks like an example of IPython's input transformers.
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 commentedon 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.
treyhunner commentedon Sep 17, 2026
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.skirpichev commentedon Sep 17, 2026
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)?
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.
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 commentedon Sep 18, 2026
+1, if the proposed feature lands we won't really need this right? :)
skirpichev commentedon Sep 18, 2026
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 commentedon 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
-iwould 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.