<br><br><div><span class="gmail_quote">On 3/19/08, <b class="gmail_sendername">"Martin v. Löwis"</b> <<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Christian Heimes schrieb:<br> <br>> In Python 3.0 the unit test for zlib is broken because in 3.0<br> > zlib.crc32() returns an unsigned long. But in Python 2.x it's a signed int.<br> ><br> > How should the issue be solved? I think the unsigned long is wrong.<br>
<br> <br>Here at the sprint people agreed that crc32 *obviously* gives<br> an unsigned number.<br> <br> It's unfortunate that Python 2.6 can't really implement that<br> very well, hence we have to keep the 2.x behavior in 2.6.<br>
In 3k, it should change.<br> <br> Regards,<br> <br>Martin</blockquote><div><br>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.<br>
<br>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.<br>
<br>My recent checkin should have fixed the py3k tests and got them returning unsigned again.<br><br></div></div>