Repository navigation
Support system readline on OS X 10.6 #51121
Description
| BPO | 6872 |
|---|---|
| Nosy | @loewis, @ronaldoussoren, @mdickinson, @ericvsmith, @zvezdan |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ronaldoussoren'
closed_at = <Date 2009-09-20.14:55:53.766>
created_at = <Date 2009-09-09.19:03:27.071>
labels = ['extension-modules', 'OS-mac', 'type-feature', 'build']
title = 'Support system readline on OS X 10.6'
updated_at = <Date 2009-09-24.20:18:12.463>
user = 'https://github.com/mdickinson'bugs.python.org fields:
activity = <Date 2009-09-24.20:18:12.463>
actor = 'mark.dickinson'
assignee = 'ronaldoussoren'
closed = True
closed_date = <Date 2009-09-20.14:55:53.766>
closer = 'ronaldoussoren'
components = ['Build', 'Extension Modules', 'macOS']
creation = <Date 2009-09-09.19:03:27.071>
creator = 'mark.dickinson'
dependencies = []
files = ['14868']
hgrepos = []
issue_num = 6872
keywords = ['patch']
message_count = 12.0
messages = ['92457', '92458', '92460', '92463', '92475', '92485', '92486', '92492', '92653', '92655', '92896', '93093']
nosy_count = 6.0
nosy_names = ['loewis', 'ronaldoussoren', 'mark.dickinson', 'eric.smith', 'zvezdan', 'purpleidea']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6872'
versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2']
Activity
mdickinson commentedon Sep 9, 2009
The readline library supplied in OS X 10.6 looks good enough to use in
Python. It would be nice to enable building with this library, to avoid
having to install GNU readline.
There's a curious off-by-one difference between Apple's readline (which,
as I understand it, is just libedit wrapped to look like libreadline)
and GNU readline: with 'n' history items, the valid indices for Apple's
readline are 0 through n-1; for GNU they're 1 through n.
I was able to get Python trunk + system readline working on OS X 10.6
using the attached patch (which obviously isn't suitable for applying,
since it breaks the build with a non-system readline). A side effect of
the patch is that readline.get_history_item and friends store the first
history entry with index 0 rather than 1:
Interestingly, the Apple-supplied Python also behaves this way:
If people think this is worth pursuing, I'll put together a proper
patch.
mdickinson commentedon Sep 9, 2009
And here's the patch.
ronaldoussoren commentedon Sep 9, 2009
I wouldn't mind having a proper patch and doing away with the need for
GNU's readline.
IMHO the patch should try to stay as close to GNU readline's interface
as possible, and should therefore fix the off-by-one difference you
mention.
BTW. I suppose the configuration (readline.parse_and_bind) needs to be
in libedit format rather than readline format. If so, we should add
something to the readline documentation about that and possibly add
something to the readline library to make it possible to detect if
readline is ultimately linked to libedit.
BTW. If you want to push the Apple's readline to the limit you should
try if it works properly with ipython. It used to cause hard crashes
with Apple's python in 10.5.
mdickinson commentedon Sep 9, 2009
Hmm. This is looking like a bigger task than I bargained for. I notice
that the readline library currently has no tests (or maybe I'm just
failing to find them). I'm not even sure how to go about writing tests
for readline.
I suppose so. I'm a bit worried about subtle bugs occurring as a result
of fixing off-by-one differences in some places and missing them in
others; it seems safer to provide direct access to the library behaviour
without trying to fix anything. Third-party stuff that wants to work with
Apple's Python is also going to have to deal with zero-based history. So
I guess I'd prefer not to fix the off-by-one difference; this would make
it even more important to provide some way for users to tell whether
they're using GNU readline or the wrapped libedit version.
Thanks for the ipython suggestion; I've never used it before, but I'll
see if I can play around with it a bit.
loewis commentedon Sep 10, 2009
I also agree that this is desirable to have, and that the readline module
should provide the GNU semantics even with a different implementation.
zvezdan commentedon Sep 10, 2009
This patch could potentially break non-Mac OS X systems.
Fortunately, I have a patch that works with systems that use GNU
readline and systems that use editline emulation. See bpo-6877.
Unfortunately, I was lingering for over a year with opening a tracker
issue for it. Last night I did the last testing session with the trunk
checkout and I did not notice that this issue has been opened in the
meantime.
Sorry for opening the double issue.
I think that the patch from bpo-6877 should be used.
zvezdan commentedon Sep 10, 2009
Also, the patch from bpo-6877 changes setup.py in a way that enables
build of the readline module on Leopard as well.
Such build is used for about two years already (Python 2.4) by several
people in my company and nobody noticed any issues on Mac OS X Leopard.
AFAICT, it works the same now on Snow Leopard.
purpleidea commentedon Sep 10, 2009
it seems to me, that any and all readline interfaces should/could
standardize to the indexing scheme as used by the language; maybe i'm
wrong, but since python is zero based, so could the readline interfaces.
it's definitely more logical for a python programmer to expect
zero-based, and the code will match with the python code.
i would propose that everything be zero-based;
this is duplicate/similar of/to http://bugs.python.org/issue6786
ronaldoussoren commentedon Sep 15, 2009
purpleidea : Whether or not indexes should be 0-based in general is beyond
the scope of this issue.
ronaldoussoren commentedon Sep 15, 2009
I've added an updated patch to bpo-6877 that implements the same 1-based
indexing as GNU's readline and also adds a note to the documentation to
warn users about the possibility of linking the readline module to
libedit.
That patch would, possibly with clearer documentation, IMHO fix this
issue.
ronaldoussoren commentedon Sep 20, 2009
This is a duplicate of bpo-6877, I'm therefore closing this one.
I've just committed a slightly updated patch from that issue to the trunk
and 3.2.
mdickinson commentedon Sep 24, 2009
Thanks for working on this, Ronald.