[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