[Python-Dev] Octal literals

[Adam Olsen]

On 2/6/06, Alex Martelli <aleaxit at gmail.com> wrote:
> 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...

I dearly hope such types do NOT subclass abstract int.  The reason is
that although they can represent an integral value they do not behave
like one.  Approximately half of all possible float values are
integral, but would you want it to subclass abstract int when
possible?  Of course not, the behavior is vastly different, and any
function doing more than just comparing to it would have to convert it
to the true int type before use it.

I see little point for more than one integer type.  long behaves
properly like an integer in all cases I can think of, with the long
exception of performance.  And given that python tends to be orders of
magnitudes slower than C code there is little desire to trade off
functionality for performance.

That we have two integer types is more of a historical artifact than a
consious decision.  We may not be willing to trade off functionality
for performance, but once we've already made the tradeoff we're
reluctant to go back.  So it seems the challenge is this: can anybody
patch long to have performance sufficiently close to int for small
numbers?


--
Adam Olsen, aka Rhamphoryncus