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

Guido van Rossum guido at python.org
Thu Dec 4 15:40:08 EST 2003

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".

If this can be made to work, I like it. class should also be hacked, and isinstance(); and who knows how many other places, but probably not too many.

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 part doesn't make sense -- the value cannot be known unless the layout is known. But it shouldn't matter -- the long methods should never be passed a short representation, because at the C level the short implementation would be invoked automatically through the vtable or type.

Of course, the long code should be careful to downcase any results in the short range to the short representation before returning it.

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.

Someone ought to try to implement this on a branch or as a patch, to see how feasible it is.

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list