Rationale for core Python numeric types

Josef Dalcolmo dalcolmo at vh-s.de
Thu Jul 15 05:09:00 EDT 2004


on 16 Jun 2004 19:40:01 -0400
aahz at pythoncraft.com (Aahz) wrote:

> maximum range of functionality.  Python 3.0 won't even offer a fixed-size
> integer type -- it'll all be the unbounded Python long type (mostly --

If that is true, many of my data acquisition programs won't work any more, because besides using the struct module, I do have a need for occasional bit fiddling (masking, concatenating, setting, resetting, toggling, shifting, rotating) of bits in a particular word that represents some register on a hardware device. 

Sure, one could write a C extension module, but most of the time I prefer having the whole program in Python.

So, if fixed lenght integers are going to disappear, I am not sure any more how to implement these bit fiddling operations any more. As far as I am concerned, they could be in a standard module and then I would really prefer to have datatypes like int8, int16, int24 ... or uint8, uint16, uint24, uint32, uint64 where the exact size is specified. That together with a small set of very low level operation (rotating, shifting, masking bits etc) would be really useful.

As someone else pointed out: what is "short"? Most wordsizes, even in C are defined only as minimum, and relative to each other. I also remember machines with a word lenght of 36 bit. Python may not the premier language to program very close to the hardware, but it is often convenient to do so anyway.

- Josef




More information about the Python-list mailing list