[Python-Dev] Int FutureWarnings and other 2.4 TODOs

[Michael Chermside]

I proposed:
> 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".

Greg Ewing writes:
> What would happen under this scheme if someone did try
> to subclass int, or long? What would isinstance() make of
> such subclasses?

Well, you could subclass long (probably renamed, but I'll use today's
names to avoid confusion) just fine. But you couldn't subclass int
because it wouldn't even be visible to a Python program. (Of course
we can't stop you from trying to subclass it in C, but then you get
what you deserve.)

Edward Loper writes:
> If we go this route, then how general should the mechanism for "merging" 
> types in Python-space (but keeping them separate in c-space) be?  I.e., 
> should this be an integer-specific change, or a general mechanism that 
> happens to be used by int?  It seems like there might be other use cases 
> for similar "merges" (string/unicode comes to mind).

I could be wrong, but I can't think of any other cases where this would
be useful. Your example of string/unicode is definitely NOT such a case:
unicode is a useful type, and string is ALSO a useful type, one with
slightly different behavior (eg: one is useful for binary data, the
other is handy for storing arabic text). You wouldn't want to go with a
solution where one of those types didn't even seem to exist from Python.

Really, the int/long thing is pretty unique, and it's because ints are
a bit special. With almost any other data type, we could just create
separate types which inherit from each other, but with ints we want them
to appear seamlessly to be the same thing as longs, yet we are willing
to grant them almost NO memory overhead. The only other type I can
think of which we want to be so small is float, and if we decided to
introduce a arbitrary precision binary based floating point type to
complement Decimal and Rational, then I think we'd need our heads
examined.

-- Michael Chermside