[Python-3000] long/int unification

[Travis Oliphant]

Guido van Rossum wrote:

> On 9/5/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
>> What impact is this long/int unification going to have on C-based
>> sub-types of the old int-type?  Will you be able to sub-class the
>> integer-type in C without carrying around all the extra backage of the
>> Python long?
>
>
> This seems unlikely given that the PyInt *type* will go away (though
> the PyInt *API* methods may well continue to exist). You can subclass
> the PyLong type just as easily. What baggage are you thinking of?

Just the extra stuff in the C-structure needed to handle the 
arbitrary-length integer.

>
> If you're thinking of the current special-casing for e.g. list[int] in
> ceval.c, that code will likely disappear (although something
> equivalent will eventually be added).

Yes, that's what I'm thinking of.   It would be nice if the "something 
equivalent" could be extended to other objects.  I suppose the 
discussion can be held off until then.

>
> But now that we have __index__, of course, there's less reason to
> subclass PyInt in the first place -- you can write your own 32-bit
> integer *without* inheriting from PyInt or PyLong, and it should be
> usable perfectly whenever an integer is expected. Id rather make sure
> *this* property is provided without compromise than attempting to keep
> random older optimizations alive for nostalgia's sake.


Of course, I agree entirely, so I doubt it will matter at all (except in 
optimizations).  There is probably going to be an increasing need to 
tell whether or not something can handle one of these interfaces.  I 
know this was already discussed on this list, but was a decision reached 
about how to tell if something exposes a specific interface? (I think 
the relevant discussion took place under the name "callable").  

I see a lot of

isinstance(obj, int)

in scientific Python code where testing for __index__ would be more 
appropriate.

Thanks for easing my mind.

-Travis