[Python-3000] long/int unification
oliphant.travis at ieee.org
Wed Sep 6 00:17:49 CEST 2006
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
> - 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
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
More information about the Python-3000