[Python-3000] long/int unification

[Guido van Rossum]

On 9/5/06, Travis Oliphant <oliphant at ee.byu.edu> wrote:
> 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.

That's just an int length and 15-for-16-bits encoding of the actual value.

> > 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.

I wouldn't rip this out just yet. 'int' may become an abstract type
yet -- the int/long unification branch isn't the final word (if only
because it doesn't pass all the unit tests yet).

> Thanks for easing my mind.

You're welcome. And how's that PEP coming? :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)