Repository navigation
Python 3.13.0b1 REPL changes behavior wrt PgUp, inserts first line of ~/.python_history #119034
Description
Activity
- changed the title
[-]Python 3.13.0b1 REPL chnages behavior wrt PgUp, inserts first line of ~/.python_history[/-][+]Python 3.13.0b1 REPL changes behavior wrt PgUp, inserts first line of ~/.python_history[/+]on May 14, 2024 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/inputrcsettings 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-wordCtrl + Right Arrowshould go forward one wordAlt + Right Arrowshould go forward one wordCtrl + Left Arrowshould go backward one wordAlt + Left Arrowshould 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-forwardPage Upshould search search backward through command historyPage Downshould 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-insertThat maps
InsertandCtrl-Vto allow a literal interpretation of the next key/character (e.g.Ctrl-V Tabshould insert a literalTabcharacter).Fedora has:
"\e[2~": overwrite-modeThat maps
InsertandCtrl-Vto 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
Reacted by Łukasz Langa and Miro HrončokI 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.)
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_REPLas this one is not getting removed.Reacted by Miro Hrončok and Trey HunnerReacted by Reid Wahl and cydwillFor 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.
The quoted-insert vs overwrite-mode inconsistency is explained in the commit message of https://pagure.io/setup/c/b8ba4814b55da50c0946dbb5b1f72e8ba452c49e
I think
Ctrl-Vshould 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 isCtrl-V, an invalid character will be input, which will result in aSyntaxError.Here's an example (I pressed
Ctrl-Vjust before the final)in theprintline 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.
We haven't gotten to that for RC1 but should be there in RC2.
Workaround for that: use CTRL+R.
Consider:
>>> import sys >>> import os >>> [CTRL+R] imI'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.
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.
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?
- added a commit that references this issue
on Sep 6, 2024
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:
Python 3.12 REPL inserts
import oswith my cursor betweenmandp. I can keep pressing PgUp to getimport sysand 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
Linked PRs