[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Michael Chermside]

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