[Python-Dev] Int FutureWarnings and other 2.4 TODOs (original) (raw)

Michael Chermside mcherm at mcherm.com
Thu Dec 4 08:56:17 EST 2003

[Guido writes:]

The implementation uses the type as the vtable of a C++ class, and the functions in the vtable "know" the representation, which is very different for short and long ints. This is all nice and efficient, except that the identity of the vtable is returned as the type of the object, so two different vtables means two different types. ... [and clipping overaggressively:] The alternative ... embed a flag ... downslide should be obvious ... extra test+branch ... also extra space ... no spare bits.

I have an idea, but don't know enough about the type mechanisms to know whether this is possible. So I'll throw it out there and let you shoot it down.

To my mind, the ideal is that there's a single type, probably called "int" or "integer" which can take on an arbitrary size and precision BUT which, if it happens to be small enough to fit in a C int will take up less memory and run faster. The fact that it's stored differently should be an implementation detail not visible to the user.

But which user? I would say that someone using the C api's to write extension modules probably DOES care about the particular representation of ints vs longs, and it's not unreasonable to expect them to deal with it. But for someone programming from Python it should "just work".

If you agree with this premise, then it suggests a different approach. Use different implementations in C, but have type(x) in Python lie. type(x) would always return the type object which is now known as "long". That type object would be smart enough to realize that any time the object it is dealing with had a value in the range [-MAXINT-1, MAXINT] that it was ACTUALLY using the layout now known as "int". This would require some clever tricks in the implementation of the "long" type object, but that's not where we care about performance. Of course, it's possible that there are no tricks clever enough to handle this -- I certainly don't know how to do it, but I wouldn't be TOO surprised if someone else here did.

-- Michael Chermside

PS: If this approach were used, the sensible type names would be something like "shortint" (visible only from C) and "int" (today's long).

More information about the Python-Dev mailing list