Fredrik Lundh wrote:
> "Jansson Christer" wrote:
>>>>I have discovered that in my Python 2.4.1 installation (on Solaris 8),
>>struct.pack handles things in a way that seems inconsistent to me.
>>>>I haven't found any comprehensible documentation over known issues with
>>Python 2.4.1 so I try this...
>>>>Here's the thing:
>>>>>>>>>from struct import pack
>>>>>pack('B', -1)
>>>>Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>>struct.error: ubyte format requires 0<=number<=255
>>>>>>>pack('H', -1)
>>>>Traceback (most recent call last):
>> File "<stdin>", line 1, in ?
>>struct.error: short format requires 0<=number<=USHRT_MAX
>>>>>>>pack('L', -1)
>>>>'\xff\xff\xff\xff'
>>>>Shouldn't pack('L', -1) raise an exception like the others, rather than
>>behaving like pack('l', -1)?
>>> probably; the reason for the old behaviour is probably to simplify for code that
> uses Python int's to represent 32-bit values. (mixing longs and ints used to be a
> lot more difficult than it is today).
>>>>Is this fixed in later versions?
>>> the "struct" module was rewritten in Python 2.5; the new module issues a
> warning, and then appears to *clamp* the value to the allowed range, in-
> stead of grabbing the low bits:
>>>>>>import struct
>>>>>>struct.pack("B", -1)
>> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "C:\Python25\Lib\struct.py", line 63, in pack
> return o.pack(*args)
> struct.error: ubyte format requires 0 <= number <= 255
>>>>>>struct.pack("H", -1)
>> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "C:\Python25\Lib\struct.py", line 63, in pack
> return o.pack(*args)
> struct.error: short format requires 0 <= number <= USHRT_MAX
>>>>>>struct.pack("I", -1)
>> __main__:1: DeprecationWarning: 'I' format requires 0 <= number <= 4294967295
> '\x00\x00\x00\x00'
>>>>>>struct.pack("L", -1)
>> __main__:1: DeprecationWarning: 'L' format requires 0 <= number <= 4294967295
> '\x00\x00\x00\x00'
>> </F>
>>>
Ok this implies that somebody is actually thinking about how to handle
this, so I guess I won't file a bug report and simply solve my problems
without relying on those exceptions...
Thank you!
--
--
Christer Jansson
WiseOne AB
+46 708 21 42 84
