[Python-3000] long/int unification (original) (raw)

Josiah Carlson jcarlson at uci.edu
Fri Aug 25 08:39:22 CEST 2006

Fredrik Lundh <fredrik at pythonware.com> wrote:

martin at v.loewis.de wrote: > I'm not sure whether this performance change is > acceptable; at this point, I'm running out of ideas > how to further improve the performance. without really digging into the patch, is it perhaps time to switch to unboxed integers for the CPython interpreter ? (support for implementation subtypes could also be nice; I agree that it would be nice if we had only one visible integer type, but I don't really see why the implementation has to restricted to one type only. this applies to strings too, of course).

In the integer case, it reminds me of James Knight's tagged integer patch to 2.3 [1]. If using long exclusively is 50% slower, why not try the improved speed approach? Also, depending on the objects, one may consider a few other tagged objects, like perhaps None, True, and False (they could all be special values with a single tag), or even just use 31/63 bits for the tagged integer value, with a 1 in the lowest bit signifying it as a tagged integer.

[1] http://mail.python.org/pipermail/python-dev/2004-July/046139.html

More information about the Python-3000 mailing list