REPL mode with vi bindings is broken in python 3.13.0 shipped in Homebrew

[tedmiddleton]

Bug report

Bug description:

I'm on MacOS 14.6.1 Sonoma using python 3.13.0 with homebrew. My understanding is that homebrew python has used libeditline since python 3.11, having previously used libreadline. I have my .editrc set up with a single command:

bind -v

On the python 3.9.6 that Apple ships with Sonoma in /usr/bin, as well as with homebrew python@3.11 and python@3.12, this works perfectly to provide us with a reasonable vi line discipline in python - pressing ESC will go into command mode, in command mode we can use most of the well-known vi shortcuts like h, l, j, k, ^, $, w, b, etc to navigate, and then press i to return to insert mode.

In python 3.13 shipped with homebrew this is somewhat broken. Pressing ESC, seems to put you into command mode (maybe?) but most of the navigation in command mode is broken.

b (back word) and f (forward word) seem to kind of work - but not completely. b will move back 1 word as expected, but then it immediately drops back into insert mode for some reason. Similarly with f - it moves forward 1 word but then goes into insert mode.

And all of the other keys in command mode seem to be completely broken - not only do they drop back into insert mode, but they don't even navigate or perform actions. Some of the things I've tested:

b - cursor moves back a word successfully, but then drops into insert mode
f - cursor moves forward a word successfully, but then drops into insert mode
h - nothing, drops into insert mode
l - nothing, drops into insert mode
^ - nothing, drops into insert mode
$ - nothing, drops into insert mode
r - nothing, drops into insert mode
cw - nothing, drops into insert mode and prints a w (c I guess is the problem here)
j - nothing, drops into insert mode
k - nothing, drops into insert mode

Python 3.13.0 (main, Oct  7 2024, 05:02:14) [Clang 16.0.0 (clang-1600.0.26.4)] on Darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

and type

>>>prunt

and then press ESC followed by b and then cw and then print, this should put python into command mode, navigate 1 word back (b) to the start of prunt, delete prunt and put us back in insert mode (cw - change word) to type out print, what we'll get instead is

>>>cwprintprunt

...while in python 3.9.6, python 3.11, and python 3.12 we get the expected

>>>print

In the case of python 3.13, I suspect the ESC puts python into command mode, the b successfully navigates to the start of prunt but it also mistakenly drops us into insert mode. Then cwprint is typed out in insert mode with the expected results.

CPython versions tested on:

3.9, 3.10, 3.11, 3.12, 3.13

Operating systems tested on:

macOS

[tedmiddleton]

Another difference I've noticed between /usr/bin/python3 (3.9.6), /opt/homebrew/python3.10, /opt/homebrew/python3.11, and /opt/homebrew/python3.12 on the one hand vs /opt/homebrew/python3.13 is that python3.13 has it's repl prompt coloured in magenta, whereas the others have it uncoloured.

Maybe this is some sort of ncurses conflict?

[ronaldoussoren]

Python 3.13 adds a new REPL, see the what's new document for more information.

PEP 762 contains more information about the new REPL and mentions that it does not use readline/editline for handling input.

[tedmiddleton]

It’s important to emphasize that the introduction of PyREPL does not remove any existing functionality. Any functionality of the old basic REPL unavailable in PyREPL is preserved and maintained in the old basic REPL that can be used by users as a fallback.

In particular, users wanting to continue using their custom input configuration in inputrc or editrc files can continue using the old basic REPL.

I guess that makes sense. I'll have to add PYTHON_BASIC_REPL = 1 to all of my config files.

I'm glad they're keeping the old REPL behaviour with it's powerful libreadline vi editing features - there are other REPL implementors with other languages (whom I will not name) who built their libreadline replacement without understanding what they were replacing and without providing a fallback.

I do hope that the cpython implementors understand, though, that many of us really do depend every day on the line discipline that libreadline gives us in the python REPL - I hope that they don't view PYTHON_BASIC_REPL as a migration aid.