This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: readline and zero based indexing
Type: enhancement Stage:
Components: Extension Modules Versions: Python 3.2
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: eric.araujo, mark.dickinson, purpleidea, terry.reedy
Priority: normal Keywords:

Created on 2009-08-26 18:17 by purpleidea, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (13)
msg91979 - (view) Author: James (purpleidea) Date: 2009-08-26 18:17
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,

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
msg92043 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2009-08-28 20:32
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.
msg92459 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-09-09 19:09
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 issue 6872.
msg92493 - (view) Author: James (purpleidea) Date: 2009-09-10 16:42
@mark: thanks for the comment; i suppose we should investigate why and
if c readline is 1 based...
msg92494 - (view) Author: James (purpleidea) Date: 2009-09-10 16:47
i found this:
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?
msg112701 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-03 21:59
I wonder if changing the base now would cause problems.
Is readline only used interactively?
msg112703 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-03 22:04
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.
msg112802 - (view) Author: James (purpleidea) Date: 2010-08-04 13:20
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...
msg112862 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-04 18:58
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.
msg112863 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-08-04 19:01
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.
msg113377 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 04:28
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.
msg113458 - (view) Author: James (purpleidea) Date: 2010-08-09 19:24
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?

msg140420 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-07-15 15:31
> 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! :)
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 51035
2011-07-15 15:31:05eric.araujosetnosy: + eric.araujo
messages: + msg140420
2010-08-09 19:24:27purpleideasetmessages: + msg113458
2010-08-09 04:28:05terry.reedysetstatus: open -> closed
resolution: rejected
messages: + msg113377

versions: - Python 3.1, Python 2.7
2010-08-04 19:01:09mark.dickinsonsetmessages: + msg112863
2010-08-04 18:58:55mark.dickinsonsetmessages: + msg112862
2010-08-04 13:20:12purpleideasetmessages: + msg112802
2010-08-03 22:04:23mark.dickinsonsettype: behavior -> enhancement
messages: + msg112703
2010-08-03 21:59:47terry.reedysetmessages: + msg112701
versions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.5
2009-09-10 16:47:23purpleideasetmessages: + msg92494
2009-09-10 16:42:11purpleideasetmessages: + msg92493
2009-09-09 19:09:26mark.dickinsonsetnosy: + mark.dickinson
messages: + msg92459
2009-08-28 20:32:16terry.reedysetnosy: + terry.reedy
messages: + msg92043
2009-08-26 18:17:34purpleideacreate