[Python-Dev] Bad interaction of index and sequence repeat (original) (raw)

Tim Peters tim.peters at gmail.com
Fri Jul 28 20:39:28 CEST 2006

[Tim]

... This is a mess :-)

[Nick Coghlan]

I've been trawling through the code a bit, and I don't think it's as bad as all that.

[also Nick, but older & wiser ;-)]

Damn, it really is a mess. . . nbindex returns the Pyssizet directly,

Bingo. It's a /conceptual/ mess. Best I can make out, Travis only cared about sequence slicing (not indexing), and then the machinery got hijacked to become a more general "can you faithfully act like an integer?" thing -- but kept a signature that made sense only for the original slicing use (where clipping is fine).

and a whole heap of the code expects errors to be signalled via returning -1 before checking PyErrOccurred().

To get it to work without clipping everywhere, wraplenfunc (typeobject.c), PyEvalSliceIndex (ceval.c), PyNumberIndex (abstract.c) and sequencerepeat (abstract.c) all had to be modified to recognize PYSSIZETMIN and PYSSIZETMAX as potential error flags (in order to clear the overflow error for PyEvalSliceIndex, and in order to propagate the exception for the other three). And using this approach still means that (2**100).index() raises an OverflowError. It would probably be cleaner to change the signature of nbindex to return a PyObject *,

Given that the more-general use is what everyone else either wanted, or simply /assumed/, in the original discussions, I expect it would be, although with the understanding that the PyObject * returned must be NULL (in case of error), or a Python int or long.

and let the code that uses it worry about how (or even whether!) to convert PyLong results to a Pyssizet.

A utility function or two could help, like one that converted to Py_ssize_t with clipping, and another that did the same but raised OverflowError if Py_ssize_t isn't big enough (and in the latter case a caller would do the usual business of checking for a -1 return and PyErr_Occurred())..

More information about the Python-Dev mailing list