trunk r61823 now compiles binascii to use zlib's crc32 rather than its own
if the zlib library is available at compile time (that should shave a
kilobyte off binascii.so on most systems).
{binascii,zlib}.crc32, zlib.adler32 and binascii.crc_hqx could all
potentially live in the hashlib module but
Hm. zlib is an odd place to find this API (unless you know way more
about gzip than healthy :-). Though binascii isn't much better. I'd
rather expect this in the vicinity of md5 and sha... Is it possible to
tweak that C code to use the zlib version if present and the old C
code otherwise?
On Tu
Both modules have a crc32 function. The zlib version is faster when zlib
has been compiled optimally or about the same when zlib is old or uses its C
code.
Should we ditch the binascii.crc32 version in py3k?
64bit Linux (CentOS 5.1):
$ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import bin
