[Python-Dev] Octal literals

[Alex Martelli]

On 2/6/06, Guido van Rossum <guido at python.org> wrote:
   ...
> What we should do in 3.0 is not entirely clear to me. It would be nice
> if there was only a single type (named 'int', of course) with two
> run-time representations, one similar to the current int and one
> similar to the current long. But that's not so easy, and somewhat
> contrary to the philosophy that differences in (C-level)
> representation are best distinguisghed by looking at the type of an
> object. The next most likely solution is to make long a subclass of
> int, or perhaps to make int an abstract base class with two
> subclasses, short and long.

Essentially, you need to decide: does type(x) mostly refer to the
protocol that x respects ("interface" plus semantics and pragmatics),
or to the underlying implementation?  If the latter,  as your
observation about "the philosophy" suggests, then it would NOT be nice
if int was an exception wrt other types.

If int is to be a concrete type, then I'd MUCH rather it didn't get
subclassed, for all sorts of both pratical and principled reasons. 
So, to me, the best solution would be the abstract base class with
concrete implementation subclasses.  Besides being usable for
isinstance checks, like basestring, it should also work as a factory
when called, returning an instance of the appropriate concrete
subclass.  AND it would let me have (part of) what I was pining for a
while ago -- an abstract base class that type gmpy.mpz can subclass to
assert "I _am_ an integer type!", so lists will accept mpz instances
as indices, etc etc.

Now consider how nice it would be, on occasion, to be able to operate
on an integer that's guaranteed to be 8, 16, 32, or 64 bits, to
ensured the desired shifting/masking behavior for certain kinds of
low-level programming; and also on one that's unsigned, in each of
these sizes.  Python could have a module offering signed8, unsigned16,
and so forth (all combinations of size and signedness supported by the
underlying C compiler), all subclassing the abstract int, and
guarantee much happiness to people who are, for example, writing a
Python prototype of code that's going to become C or assembly...

Similarly, it would help a slightly different kind of prototyping a
lot if another Python module could offer 32-bit, 64-bit, 80-bit and
128-bit floating point types (if supported by the underlying C
compiler) -- all subclassing an ABSTRACT 'float'; the concrete
implementation that one gets by calling float or using a float literal
would also subclass it... and so would the decimal type (why not? it's
floating point -- 'float' doesn't mean 'BINARY fp';-).  And I'd be
happy, because gmpy.mpf could also subclass the abstract float!

And then finally we could have an abstract superclass 'number', whose
subclasses are the abstract int and the abstract float (dunno 'bout
complex, I'd be happy either way), and Python's typesystem would
finally start being nice and cleanly organized instead of
grand-prarie-level flat ...!-)


Alex