[Python-Dev] __index__ clipping
Travis E. Oliphant
oliphant.travis at ieee.org
Thu Aug 10 04:46:11 CEST 2006
Guido van Rossum wrote:
> Here's another issue where Neal thought it would be useful if I
> weighed in. I'm not quite sure of the current status, but perhaps the
> following would work?
>
> - Called from Python, (10**10).__index__() should return 10000000000L,
> not raise an exception or return sys.maxint.
>
> - The nb_index slot is changed to return an object; it should return a
> Python int or long without clipping (same as __index__() called from
> Python).
I don't like this approach because nb_int and nb_long are already
available to convert an object into an int or a long, so the only value
of nb_index is to make sure that floats aren't able to be converted this
way.
The value of nb_index is that it provides a "small-overhead" means to
quickly convert any object that allows it into a Py_ssize_t value which
is needed in many internal situations (mostly indexing related).
Rather than assume a Python integer is the only candidate for conversion
to a Py_ssize_t value, nb_index allows other objects to be used in that
fashion. Having another level of indirection where one object is first
converted to a Python int or Python long (whichever is needed) and then
to a Py_ssize_t value seems like un-necessary waste to me and will
needlessly slow certain indexing operations down.
It seems like Nick's recent patches solved the problems that were
identified.
-Travis
>
> - There should be three C APIs (perhaps fewer if some of them are never needed):
>
> - One to call the nb_index slot, or raise an exception if it's not
> set, returning the object
>
> - One to return the clipped value without an exception
> (can still return an exception if something else went wrong)
>
> - One to return the value if it fits, raise OverflowError if it doesn't
>
> I know this is quite the deviation from the current code but it seems
> the most rational and future-proof approach.
>
More information about the Python-Dev
mailing list