On 5/29/06, Bob Ippolito <bob@redivi.com> wrote:
Well, the behavior change is in response to a bug <
http://python.org/sf/1229380>. If nothing else, we should at least fix the standard library such that it doesn't depend on struct bugs. This is the only way to find them :)
Feel free to comment how the zlib.crc32/gzip co-operation should be fixed. I don't see an obviously correct fix. The trunk is currently failing tests it shouldn't fail. Also note that the error isn't with feeding signed values to unsigned formats (which is what the bug is about) but the other way 'round, although I do believe both should be accepted for the time being, while generating a warning.
Basically the struct module previously only checked for errors if you don't specify an endian. That's really strange and leads to very confusing results. The only code that really should be broken by this additional check is code that existed before Python had a long type and only signed values were available.
Alas, reality is different. The fundamental difference between types in Python and in C causes this, and code using struct is usually meant specifically to bridge those two worlds. Furthermore, struct is often used *fix* that issue, by flipping sign bits if necessary:
>>> struct.unpack("<l", struct.pack("<l", 3221225472))
(-1073741824,)
>>> struct.unpack("<l", struct.pack("<L", 3221225472))
(-1073741824,)
>>> struct.unpack("<l", struct.pack("<l", -1073741824))
(-1073741824,)
>>> struct.unpack("<l", struct.pack("<L", -1073741824))
(-1073741824,)
Before this change, you didn't have to check whether the value is negative before the struct.unpack/pack dance, regardless of which format character you used. This misfeature is used (and many would consider it convenient, even Pythonic, for struct to DWIM), breaking it suddenly is bad.