Let me reopen this, I think we have an issue with this fix.

The conclusion of this discussion so far is that in 3.0 the crc32 will
behave like the standard, which is a good thing (tm), but in 2.6 it will
not: it should return a signed integer. I agree with this outcome!

The documentation for 2.6, the commit message for the fix and what it's
said here states that: "2.6 always returns signed, 2**31...2**31-1 come
back as negative integers."

This is *not* actually happening:

>>> s = "*"*100000
>>> print zlib.crc32(s)  # 2.6, 32 bits
-872059092
>>> print zlib.crc32(s)  # 2.6, 64 bits
3422908204

The problem in the code is, IMHO, that the "32b rounding" is being
forced by assigning the result to an int (Modules/zlibmodule.c, line
929), but this "rounding" does not actually work for 64b (because the
int has 64 bit, and even as it's signed, the number stays big and positive).

Thank you!