[EMAIL PROTECTED] 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
