kwsp
(Taylor Nie)
December 12, 2023, 5:28pm
1
CPython for Unix builds with GNU readline, which doesn’t support Windows, so the user experience in the Windows Python REPL is much worse compared to Unix. I would like for the Windows REPL to at least support keybinds like C-P
, C-N
, C-A
, C-E
etc. I know this is a complicated problem and I’ve found a lot of related issues on Github, but none of them specifically mention the usability of the Windows REPL or the implementation of readline-like features for Windows as a main issue.
For inspiration, Node.js emulates most readline features through an internal javascript library .
My question: Is there anything substantial blocking the removal of GNU readline as a dependency (for a custom cross-platform implementation)? If the worry is breaking API or breaking other applications, what specific readline API does python expose?
pf_moore
(Paul Moore)
December 12, 2023, 5:53pm
2
Not worse, just different. I find the Windows experience very comfortable (and consistent with all the other Windows CLI programs I use) whereas the Unix experience is unfamiliar and frustrating.
People’s tastes vary.
If you want readline support in WIndows, you can install a readline library (which admittedly you’ll have to find yourself) and Python will recognise it and activate the same readline support as used in Unix.
kwsp
(Taylor Nie)
December 12, 2023, 7:08pm
3
Is this true? Could you please point to the documentation or source code where CPython activates readline for Windows if a library is found? AFAIK from reading the docs and source code, the builtin readline module could support the readline emulation library of editline/libedit
, but runtime detection is only done on macOS
In the PC build config header, I found this:
But this macro isn’t used anywhere else in the code base.
pf_moore
(Paul Moore)
December 12, 2023, 8:06pm
4
Sorry I misremembered. What is needed is a readline
module that implements the interface documented in the stdlib. The pyreadline project provided such a module on Windows. It’s not been updated since 2015 so it may be unmaintained these days. But I’m sure someone with enough interest could check if it still works and bring it up to date.
kwsp
(Taylor Nie)
December 12, 2023, 10:13pm
5
Compiling more issues related to CPython’s use of readline/editline
Closed:
opened 02:25AM - 29 Nov 23 UTC
closed 02:12PM - 01 Dec 23 UTC
type-feature
# Feature or enhancement
### Proposal:
Currently we support two backends with … readline: GNU readline and editline. They work in a similar way but have some differences. Notably the way to set `<tab>` as the complete key.
The users need to distinguish the backend at run time, and currently the recommended way is:
```python
if 'libedit' in getattr(readline, '__doc__', ''):
```
We have worse checks like
```python
readline_doc = getattr(readline, '__doc__', '')
if readline_doc is not None and 'libedit' in readline_doc:
```
in `site.py`.
It would be nice to provide a more official and clean way to check the backend, instead of querying for the docstring for the module. This is also mentioned in https://github.com/python/cpython/pull/107748#discussion_r1395432432 by @encukou .
In this proposal, a new attribute `backend` is added which could be either `readline` or `editline`.
### 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_
### Linked PRs
* gh-112511
Open:
opened 12:05AM - 30 Dec 22 UTC
type-bug
OS-mac
# Bug report
With the following in `~/.editrc`:
```
bind "^R" em-inc-sear… ch-prev
```
Pressing `CTRL+R` inside the macOS-bundled python (/usr/bin/python3, which is compiled against editline) to enter editline history, and then pressing `CTRL+C` does not properly remove "bck" and does not write KeyboardInterrupt until CTRL+C is pressed two more times for a total of three times.
In other words, inside an editline history search, CTRL+C needs to be sent three times to get back to the normal REPL state.
This video may help with understanding the issue: https://github.com/Homebrew/homebrew-core/issues/118869#issuecomment-1365364374
# Your environment
- CPython versions tested on: 3.9.6
- Operating system and architecture: macOS Monterey 12.6.1 / M1 / arm64
opened 09:45PM - 21 Feb 23 UTC
type-bug
stdlib
# Bug report
As title, the Homebrew community has switched to libedit readlin… e as of Python 3.11. There exists a gnureadline package which allows one to continue using the gnu readline, but unfortunately cmd.py will continue to use the libedit one, and that doesn't always work properly.
# Your environment
Python 3.11 MacOs Ventura.
Here's some code that won't work with libedit readline:
```python
import cmd
class MyShell(cmd.Cmd):
def do_command(self, _arg):
print(f"running {self}")
MyShell().cmdloop()
```
Tab-completion appears to fail on Homebrew python 3.11, I suspect due to the libedit readline. The code works fine with Homebrew python versions up to 3.10 which use gnu readline. Also, if you install gnureadline and change all occurrences of `import readline` in cmd.py to `import gnureadline as readline` the cmd module works perfectly.
So in summary could we fix cmd.py to work correctly with libedit as well as gnu readline? Or, failing that provide some fairly easy means of overriding the readline used by cmd.py without resorting to nasty monkey patching.
### Linked PRs
* gh-107738
* gh-107748
opened 12:05AM - 30 Dec 22 UTC
type-bug
OS-mac
# Bug report
With the following in `~/.editrc`:
```
bind "^R" em-inc-sear… ch-prev
```
Pressing `CTRL+R` inside the macOS-bundled python (/usr/bin/python3, which is compiled against editline) to enter editline history, and then pressing `CTRL+C` does not properly remove "bck" and does not write KeyboardInterrupt until CTRL+C is pressed two more times for a total of three times.
In other words, inside an editline history search, CTRL+C needs to be sent three times to get back to the normal REPL state.
This video may help with understanding the issue: https://github.com/Homebrew/homebrew-core/issues/118869#issuecomment-1365364374
# Your environment
- CPython versions tested on: 3.9.6
- Operating system and architecture: macOS Monterey 12.6.1 / M1 / arm64