[Python-Dev] Int FutureWarnings and other 2.4 TODOs (original) (raw)
Andrew Koenig ark-mlist at att.net
Tue Dec 2 16:25:41 EST 2003
- Previous message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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).
Got it.
> 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.
I think that int should be the base class, because I can imagine long supporting operations that int does not support, but not vice versa.
- Previous message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]