[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Guido van Rossum]

> > I'm not sure about that yet.  I'd *like* to find a hack that lets the
> > int type change representations, but the fact is that it's much easier
> > to use different types to indicate different representations.
> 
> Aren't integers immutable?  If so, I would think it doesn't make sense for
> them to change representation, as they don't change value.

I was using shorthand-speak meaning that different instances of the
same class would use a different representation (which the class can
somehow recognize by looking at the instance, of course).

> Anyway, if you want to use type to encode representation, I would
> think that the various integer types should be related by
> inheritance.  As a long can always substitute for an int, at least
> in theory, I would think that long should be derived from int.  Then
> isinstance(42L, int) would yield True.

Or should int be a subclass of long?  I believe that OO theorists
consider the base class the set with the largest number of elements
(since it is the least constrained).  Now, all ints are longs, but all
longs are not ints, since ints can only represent values in
[-sys.maxint-1, sys.maxint].  According to this reasoning, long should
be the base class.

But the naming suggests different: 'int' suggests no particular size
(except to C/C++ users :-) so should be the more general class, and
that pleads for your version.

I don't particularly like either approach, because the 'long' type is
an implementation detail over which the user has no control (this is a
change of heart since Python's original design!).  I guess that means
I have to work harder and make the single int type support both
representations.  I'm sure it can be done.

> If integers are related this way, LSP implies that converting a long
> to a string should not put an L at the end.

Well, they aren't in Python 2.x, which is why the L stays until 3.0.

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