[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Guido van Rossum]

> 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/)