[Python-Dev] Octal literals (original) (raw)

Alex Martelli aleaxit at gmail.com
Mon Feb 6 20:00:10 CET 2006

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

More information about the Python-Dev mailing list