On 3/19/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Christian Heimes schrieb: > > > In Python 3.0 the unit test for zlib is broken because in 3.0 > > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed > int. > > > > How should the issue be solved? I think the unsigned long is wrong. > > > Here at the sprint people agreed that crc32 *obviously* gives > an unsigned number. > > It's unfortunate that Python 2.6 can't really implement that > very well, hence we have to keep the 2.x behavior in 2.6. > In 3k, it should change. > > Regards, > > Martin
yes crcs should be unsigned; they're fixed size bit fields. it could even make sense to return them as a 4 byte bytes/str object but that'd be an API change. a sign requires you to assume you know the length of the underlying integer holding it. python ints and longs don't have a fixed size so that is troublesome and leads to lots of zlib.crc32(foo) & 0xffffffff and binascii.crc32(foo) & 0xffffffff or other ugly tricks to un-sign the value. I could make 2.6 return unsigned but it would mean that it returns a long half of the time rather than an int. The informal consensus in the room earlier this week was to leave 2.x returning a signed value for compatibility (I made it consistent so that it -always- returns a signed regardless of sizeof(long)). i'd be happy either way. My recent checkin should have fixed the py3k tests and got them returning unsigned again.
_______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
