readline and zero based indexing

[purpleidea]

BPO	6786
Nosy	@terryjreedy, @mdickinson, @merwok

^{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 = None
closed_at = <Date 2010-08-09.04:28:05.379>
created_at = <Date 2009-08-26.18:17:34.742>
labels = ['extension-modules', 'type-feature']
title = 'readline and zero based indexing'
updated_at = <Date 2011-07-15.15:31:05.356>
user = 'https://bugs.python.org/purpleidea'

bugs.python.org fields:

activity = <Date 2011-07-15.15:31:05.356>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2010-08-09.04:28:05.379>
closer = 'terry.reedy'
components = ['Extension Modules']
creation = <Date 2009-08-26.18:17:34.742>
creator = 'purpleidea'
dependencies = []
files = []
hgrepos = []
issue_num = 6786
keywords = []
message_count = 13.0
messages = ['91979', '92043', '92459', '92493', '92494', '112701', '112703', '112802', '112862', '112863', '113377', '113458', '140420']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'mark.dickinson', 'eric.araujo', 'purpleidea']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6786'
versions = ['Python 3.2']

[purpleidea]

why is it that the zeroth readline history item is seemingly always
none. I would expect this to support zero-based indexing in python, but
perhaps I have missed some detail in readline somewhere. Cheers,
_J

james@work:~$ python
Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49) 
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline.get_history_item(0)
>>> readline.get_history_item(0) is None
True
>>> 
james@work:~$

[terryjreedy]

Please ask questions on, for instance, the python-list (c.l.p).

If you find evidence that this is actually a bug, please supply.
Else, close (or change to doc issue -- see below).

My *guess* is that history lists are 1-based and Python conforms to that.
If so, the doc should mention that. But I do not know.

[mdickinson]

I'd guess the same. Most of the readline module is just a thin wrapper
around the system readline library, so if the system readline library uses
one-based indexing, so does the readline module. Changing this would
probably be quite error-prone, with a high chance of introducing off-by-
one errors somewhere along the line.

Interestingly, the Apple-supplied python (2.6.1) in OS X 10.6 does have
zero-based readline history. See bpo-6872.

[purpleidea]

@mark: thanks for the comment; i suppose we should investigate why and
if c readline is 1 based...

[purpleidea]

i found this:
http://tiswww.case.edu/php/chet/readline/history.html
search for: "Variable: int history_base"
perhaps we can set this to 0 in the python bindings.
more so, perhaps someone is using 1 because they made a mistake?

[terryjreedy]

I wonder if changing the base now would cause problems.
Is readline only used interactively?

[mdickinson]

Changing to feature request: I'm fairly certain that this isn't a bug (i.e., it's working as designed).

It's possible to use the readline module non-interactively, so it's probably a safe bet that there's at least some code out there that does so.

I'd vote to reject this; I agree it would have been nicer if indexing had started from 0 originally, but the 1-based indexing doesn't really seem like a big deal.

[purpleidea]

It's an incompatible change; it would definitely break my code, however I think it should be wishlisted for an API-break release like 3.5 or 4.0 or something like that. IMHO, the bindings should be "pythonic", even if the underlying library isn't.

In addition, maybe we could add a readline.set_zero_based_indexing() function? I could write a patch for this perhaps...

[mdickinson]

A patch would be useful: I don't think this issue is going to go anywhere without one.

One of the reasons I'm reluctant to mess with the readline module more than necessary is that it's historically been fairly fragile: it has to work not only with a number of different GNU readline versions, but also with libedit on OS X and BSD (and OS X universal builds add an extra layer of complexity), and there have been a number of readline-related build problems in the past.

[mdickinson]

Postscript: I'm also opposed to the idea of 'optional' zero-based indexing. This just seems like a crazy level of micro control to me. Better to have just the one way way to do it, even if it isn't quite pythonic.

[terryjreedy]

I do not see a change as being accepted. It would not add any new function but probably break code, if not habits, for the sake of consistency that would have been nice.

[purpleidea]

I'd be writing a patch which would allow a programmer the option to explicitly use/instantiate the library in a zero-based way. This way throughout their particular program, the indexing of elements could be consistent. Not having this causes you to have to reason differently about which parts should be list[i+1] versions list[i].

Would this be reasonable?
Thanks,

_J

[merwok]

I'd be writing a patch which would allow a programmer the option to
explicitly use/instantiate the library in a zero-based way. [...]
Would this be reasonable?

I think not. Mark already stated his opposition to “a crazy level of micro control”. Such a patch would not be trivial but would not bring much.

I hope you’ll find other bugs that motivate you for a patch! :)