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).<br><br>{binascii,zlib}.crc32, zlib.adler32 and binascii.crc_hqx could all potentially live in the hashlib module but their APIs are a notably different as they return a number rather than a string (leaving serialization byte order up to the user and are functions that allow passing in the start value rather than objects that maintain an internal state to be retrieved when done adding data. It'd be easy enough to wrap them to have the same API in python but that'd destroy any speed benefit.<br>
<br>The hashlib documentation and docstring mention that people should look at zlib if they want crc32 or adler32. IMHO thats enough even if zlib (or binascii) is a "weird" place in an overly logical sense. They're not really the same class of hash function.<br>
<br>-g<br><br><div class="gmail_quote">On Thu, Mar 20, 2008 at 12:02 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hm. zlib is an odd place to find this API (unless you know way more<br>
about gzip than healthy :-). Though binascii isn't much better. I'd<br>
rather expect this in the vicinity of md5 and sha... Is it possible to<br>
tweak that C code to use the zlib version if present and the old C<br>
code otherwise?<br>
<div><div></div><div class="Wj3C7c"><br>
On Tue, Mar 18, 2008 at 3:21 PM, Gregory P. Smith <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
> Both modules have a crc32 function. The zlib version is faster when zlib<br>
> has been compiled optimally or about the same when zlib is old or uses its C<br>
> code.<br>
><br>
> Should we ditch the binascii.crc32 version in py3k?<br>
><br>
> 64bit Linux (CentOS 5.1):<br>
><br>
> $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import binascii as mod'<br>
> 'f = mod.crc32' 'for x in xrange(100000): f(foo)'<br>
> 10 loops, best of 3: 108 msec per loop<br>
> $ python2.4 -m timeit 'foo="abcdefghijklmnop"*10' 'import zlib as mod' 'f =<br>
> mod.crc32' 'for x in xrange(100000): f(foo)'<br>
> 10 loops, best of 3: 40.5 msec per loop<br>
><br>
> 32bit MacOS X 10.4:<br>
><br>
> % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import<br>
> binascii as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'<br>
> 10 loops, best of 3: 7.37e+04 usec per loop<br>
> % python2.3 /usr/lib/python2.3/timeit.py 'foo="abcdefghijklmnop"*10' 'import<br>
> zlib as mod' 'f = mod.crc32' 'for x in xrange(100000): f(foo)'<br>
> 10 loops, best of 3: 4.62e+04 usec per loop<br>
><br>
> Removal from binascii would break things for platforms or embedded systems<br>
> wanting crc32 that don't want to include zlib. Anyone care?<br>
><br>
> What about 2.x? if we remove the redundancy in py3k i guess we deprecate<br>
> binascii.crc32 and remove in 2.7?<br>
><br>
> -gps<br>
><br>
</div></div>> _______________________________________________<br>
> Python-3000 mailing list<br>
> <a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/python-3000" target="_blank">http://mail.python.org/mailman/listinfo/python-3000</a><br>
> Unsubscribe:<br>
> <a href="http://mail.python.org/mailman/options/python-3000/guido%40python.org" target="_blank">http://mail.python.org/mailman/options/python-3000/guido%40python.org</a><br>
><br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
--Guido van Rossum (home page: <a href="http://www.python.org/%7Eguido/" target="_blank">http://www.python.org/~guido/</a>)<br>
</font></blockquote></div><br>