[Python-Dev] Is PEP 237 final -- Unifying Long Integers and Integers

Shane Hathaway shane at hathawaymix.org
Tue Jun 21 09:49:19 CEST 2005


Keith Dart wrote:
> I guess I just clarify this more. My "unsigned" type really is an object
> that represents a type of number from the external system. Previously,
> there was a nice, clean mapping between external types and Python types.
> Now there is not so clean a mapping. Not that that makes it a problem
> with Python itself.
> 
> However, since it is sometimes necessary to interface to other systems
> with Python, I see no reason why Python should not have a full set of
> built in numeric types corresponding to the machine types and, in turn,
> other system types. Then it would be easier (and probaby a bit faster)
> to interface to them. Perhaps Python could have an "integer" type for
> long/int unified types, and just "int" type as "normal" integers?

For your purposes, would it work to use the struct module to detect
overflows early?

>>> import struct
>>> struct.pack('i', 2 ** 33)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: long int too large to convert to int

Another possibility would be to add to the "struct" module a full set of
integer types with a fixed width: int8, uint8, int16, uint16, int32,
uint32, int64, and uint64.  Code that's focused on integration with
other languages might benefit.

Shane


More information about the Python-Dev mailing list