<br><br><div><span class="gmail_quote">On 3/19/08, <b class="gmail_sendername">&quot;Martin v. L÷wis&quot;</b> &lt;<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>&gt; 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>&gt; In Python 3.0 the unit test for zlib is broken because in 3.0<br> &gt; zlib.crc32() returns an unsigned long. But in Python 2.x it&#39;s a signed int.<br> &gt;<br> &gt; 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&#39;s unfortunate that Python 2.6 can&#39;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&#39;re fixed size bit fields.&nbsp; it could even make sense to return them as a 4 byte bytes/str object but that&#39;d be an API change.&nbsp; a sign requires you to assume you know the length of the underlying integer holding it.&nbsp; python ints and longs don&#39;t have a fixed size so that is troublesome and leads to lots of zlib.crc32(foo) &amp; 0xffffffff and binascii.crc32(foo) &amp; 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.&nbsp; 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)).&nbsp; i&#39;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>