[Python-3000] long/int unification

[Guido van Rossum]

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?

> NumPy has a scalar-type that inherits from the current int-type which
> allows it to participate in many Python optimizations.  Will the ability
> to do this disappear?

What kind of optimizations are you thinking of?

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

See my message about premature optimization in the Py3k from about 10 days ago.

> I'm just wondering about the C-side view of the int/long unification.  I
> can see benefit to the notion of integer unification, but wonder if
> strictly throwing out the small integer type on the C-level is actually
> going too far.  In NumPy, we have 10 different integer data-types
> corresponding to what can be contained in an array.  This direction was
> chosen after years of frustration of trying to fit a square peg (the
> item from the NumPy array) into a square hole (the limited Python scalar
> types).

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.

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