New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
binascii.crc32() - document signed vs unsigned results #49153
Comments
The result of binascii.crc32() is different on the same input in Python Python 2.6: >>> binascii.crc32('Hello')
-137262718 Python 3.0: >>> binascii.crc32(b'Hello')
4157704578 |
When treated as an unsigned 32bit value those are identical. Guido prefers to keep Python 2.x always having signed values for the See also http://bugs.python.org/issue1202 I posted a workaround in there. Always & the crc32() or adler32() |
Can someone PLEASE make sure this gets documented someplace. |
What is "this" that you want to get documented? Can you propose a |
Placing a note in the standard library documentation would be a start. Note: Not everyone uses checksums in only a packed-binary format. |
Agreed, we failed to mention the behavior change in the docs. I'll take 2to3 could presumably be made to notice crc32 and adler32 calls and warn |
binascii and zlib documentation updated in trunk r68535. I'll close the Any objections to the wording? http://svn.python.org/view/python/trunk/Doc/library/binascii.rst? |
Just a small note on the wording: "will have" and "will always be" look |
wording updated in r69159, thanks. |
and r69161, r69160, r69162, r69163, r69164. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: