[Python-3000] long/int unification
oliphant at ee.byu.edu
Wed Sep 6 01:25:06 CEST 2006
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
> 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
in scientific Python code where testing for __index__ would be more
Thanks for easing my mind.
More information about the Python-3000