[Python-3000] long/int unification

[Travis Oliphant]

martin at v.loewis.de wrote:
> Here is a quick status of the int_unification branch,
> summarizing what I did at the Google sprint in NYC.
> 
> - the int type has been dropped; the builtins int and long
>   now both refer to long type
> - all PyInt_* API is forwarded to the PyLong_* API. Little
>   changes to the C code are necessary; the most common offender
>   is PyInt_AS_LONG((PyIntObject*)v) since I completely removed
>   PyIntObject.
> - Much of the test suite passes, although it still has a number
>   of bugs.
> - There are timing tests for allocation and for addition.
>   On allocation, the current implementation is about a factor
>   of 2 slower; the integer addition is about 1.5 times slower;
>   the initial slowdowns was by a factor of 3. The pystones
>   dropped about 10% (pybench fails to run on p3yk).

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?

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?

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

-Travis