Pasting code with completely empty lines does not work in interactive mode

Sometimes I’m lazy and I would test code copy - pasted from internet or from other sources directly in the interpreter, in interactive mode. But if the code contains completely blank lines, the copy - paste fails. For example:

def f():


does not work, but

def f():

yes. Notice that in a script the first code block is perfectly valid and works.

PS: yes, I know, I can use jupiter…

This has been like this for decades so I don’t expect this to change. You’re probably better off seeing if you can get your code editor or find one that you like which will support what you’re after.


EDIT: why is it in “Ideas”? It’s not an “idea”.

The reason it works this way is because in the interactive interpreter, statements are executed as soon as you end them. That’s a convenient thing to do, interactively. It means you can do:

>>> def some_function():
...     <code here>


>>> for item in something:
...     <code here>

… and then immediate use the result: tab-complete the function, inspect the function, see the result of the loop, see it running, etc. Using something other than an empty line means you need a different trigger to know when to execute things. What should that be? An explicit key binding? Measuring the delay between the lines? Some other heuristic? It’s difficult to come up with something that doesn’t disrupt the flow of existing users of the interactive interpreter.

And keep in mind that it’s just a blank line that makes the interactive interpreter execute the statement. Any kind of whitespace on the line makes it not end the block, and it doesn’t have to match the indentation of the rest of the code. If this is just about pasting code, you could add a space in any blank line that doesn’t precede an unindented line. (It just requires that you can see the next line, which is not something the interactive interpreter can do.)

IPython solves this using bracketed paste mode.

1 Like

Yes. Why CPython doesn’t simply copy Jupyter (aka IPython) code that implement this? I mean, it’s open source :smiley:

Because the interactive interpreter isn’t IPython, so it can’t just copy the code. If you want to try and re-implement the same logic in the guts of the CPython interpreter that is the interactive part, I’m sure patches would be welcome.

@thomas: I’m busy to finish the CPython implementation of a frozendict. And after that I would to try to test C11 unicode in CPython and see if there’s a significant speed-up. After that I want to do the same with restrict. And I think all this work will end, or slow down dramatically, when I will have no more time… :smiley:

But I suppose this worth to be added to the CPython TODO list? What is more indicated, a bug report or a PEP?

There isn’t a single TODO list for CPython. A PEP won’t be useful unless there’s something to discuss. A bug, perhaps, but a PR would be better.

It is an idea because this isn’t a user question asking for help, but an idea to change the way the REPL functions. If you were posting this to a mailing list it would have gone to python-ideas, hence I moved it to the “Users” category.

Personally, because I don’t expect it to be a high-enough priority for anyone to implement as a feature request due to IPython already existing for an enhanced REPL experience and we have so many other more pressing things to work on. I also know how touchy this sort of pasting action can be due to my work with the Python extension for VS Code.

As Thomas said, you can try to write up a patch for people to play with to see if people like this idea, but I personally don’t want you getting your hopes up too high that someone is going to make this change for you.

Well, I opened

Yes, but I think Jupyter console does even too much… and if you read the bug reporting, I propose to include some Jupyter features, but in a different manner. For example, IMHO the Python console should not use magic words, since they are not Python code.

Okay, I do not hold my breath… :smiley: