Python 3.13.0b1 REPL changes behavior wrt PgUp, inserts first line of ~/.python_history

[hroncok]

Bug report

Bug description:

When I use the Python REPL, I am used to PgUp browsing my prompt history based on the partial command I already typed.

Consider:

>>> import sys
>>> import os
>>> ...
>>> im[PgUp]

Python 3.12 REPL inserts import os with my cursor between m and p. I can keep pressing PgUp to get import sys and older commands from my history. I don't know if this is Fedora's configuration of readline, or the default. However, Bash and older Python REPLs behave that way, as well as IPython/Jupyter console.

Python 3.130b1 REPL changes my prompt to print("a") when I press PgUp. The particular command is my first line of ~/.python_history. Pressing PgUp again changes nothing.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

[treyhunner]

Was talking to @ambv about this and decided to do some research on Ubuntu and Fedora's settings.

I did some research on the default /etc/inputrc settings on Ubuntu and Fedora and found these files as defaults.

Digging into the details of those, here's what's missing...

Consistencies

Here are some seemingly missing key bindings that seem to be consistently mapped between Ubuntu and Fedora's default /etc/inputrc:

"\e[1;5C": forward-word
"\e[1;5D": backward-word
"\e[5C": forward-word
"\e[5D": backward-word
"\e\e[C": forward-word
"\e\e[D": backward-word

• Ctrl + Right Arrow should go forward one word
• Alt + Right Arrow should go forward one word
• Ctrl + Left Arrow should go backward one word
• Alt + Left Arrow should go backward one word

Both Ubuntu and Fedora map those arrow shortcuts.

Only Fedora maps these ones:

"\e[5~": history-search-backward
"\e[6~": history-search-forward

• Page Up should search search backward through command history
• Page Down should search search forward through command history

Since Ubuntu doesn't map these at all, it seems safe to enable these.

Inconsistent

Ubuntu has:

"\e[2~": quoted-insert

That maps Insert and Ctrl-V to allow a literal interpretation of the next key/character (e.g. Ctrl-V Tab should insert a literal Tab character).

Fedora has:

"\e[2~": overwrite-mode

That maps Insert and Ctrl-V to enable overwrite mode instead.

Summary

The missing keybindings that should probably be added are:

• Ctrl-Left and Alt-Left: back one word
• Ctrl-Right and Alt-Left: forward one word
• Page Up: search history backward
• Page Down: search history forward

[hroncok]

I wonder if the REPL could somehow inherit/use the inputrc settings. That way, the experience will be the same with other REPLs on the same system.

(I am not saying that is a requirement. I would gladly accept a fix that makes my environment consistent.)

[ambv]

Thanks Trey for the research, we will be implementing that.

Miro, we won't be parsing inputrc, it is too advanced of a configuration format to accommodate. And it entails out-of-scope things like an vi edit mode that I already rejected. And on macOS we would have to also take editrc into account, which is yet another format, and also overly complex.

We will implement the safe defaults and keep it at that. People very invested in their inputrc can keep using PYTHON_BASIC_REPL as this one is not getting removed.

[hroncok]

For the record, I found Fedora's inputr source at https://pagure.io/setup/blob/master/f/inputrc -- in case somebody wants to take a look without spinning up a container/VM.

[hroncok]

The quoted-insert vs overwrite-mode inconsistency is explained in the commit message of https://pagure.io/setup/c/b8ba4814b55da50c0946dbb5b1f72e8ba452c49e

[treyhunner]

I think Ctrl-V should also be specially handled/ignored, since it didn't cause issues in the old Python REPL but does in the new REPL currently.

If I type print(n^V) into the new REPL, where ^V is Ctrl-V, an invalid character will be input, which will result in a SyntaxError.

Here's an example (I pressed Ctrl-V just before the final ) in the print line below:

>>> numbers = [2, 1, 3, 4, 7, 11]
>>> for n in numbers:
...     print(n)
  File "<unknown>", line 2
    print(n)
           ^
SyntaxError: invalid non-printable character U+0016

I also managed to insert a null byte while teaching in the new Python REPL today. I assume I hit a keyboard combination that did this, but I'm not sure which one.

>>> names = ['Nellie', 'Ronald', 'Judith', 'Lavonda']
>>> for i in range(len(name)):
SyntaxError: source code string cannot contain null bytes

I'll comment here or open a separate issue if I manage to reproduce the null byte I inserted.

[hroncok]

I also noticed pressing Delete inserts ~ in some environments instead of deleting the character right to the cursor. Not sure if this is related or not. Should I open separate issue?

[hroncok]

Thanks Trey for the research, we will be implementing that.

@ambv Is this something I should explore to implement myself if I want this fixed?

[ambv]

There's an open PR about this in the duplicate issue gh-120767.

[ambv]

We haven't gotten to that for RC1 but should be there in RC2.

[hroncok]

https://github.com/python/cpython/issues/120767 does not seem like a duplicate to me. It speaks about arrows up and down, not PageUp/PageDown. As does https://github.com/python/cpython/pull/121859

[vstinner]

Workaround for that: use CTRL+R.

Consider:

>>> import sys
>>> import os
>>> [CTRL+R] im

I'm using a different shortcut for that which works on bash and all Python versions:

• CTRL+R to search in the history
• Type im
• Press CTRL+R again to iterate in results starting with im

There is also CTRL+S to search forward in the history.

[hroncok]

Thanks, I am aware of Ctrl+r. The PageUp thing is better when I already strated to type the command. It's really convenient and not having it makes my REPL experience in 3.13 seriously degraded.

Omce again, should I submit a PR? I don't want to step on other people toes, but it's been a while and the window to get this into 3.13 is closing.

[vstinner]

Omce again, should I submit a PR? I don't want to step on other people toes, but it's been a while and the window to get this into 3.13 is closing.

I just wrote PR gh-123607 to implement these commands (history search backward/forward). Can you please test it and tell me if it behaves as expected?