fyi - i've updated the python sha1/md5 openssl patch. it now replaces the entire sha and md5 modules with a generic hashes module that gives access to all of the hash algorithms supported by OpenSSL (including appropriate legacy interface wrappers and falling back to the old code when compiled without openssl).
https://sourceforge.net/tracker/index.php?func=detail&aid=1121611&group_id=5470&atid=305470
I don't quite like the module name 'hashes' that i chose for the generic interface (too close to the builtin hash() function). Other suggestions on a module name? 'digest' comes to mind.
'hashtools' and 'hashlib' would both have precedents in the standard library (itertools and urllib, for example).
It occurs to me that such a module would provide a way to fix the bug with incorrectly hashable instances of new-style classes:
Py> class C: ... def __eq__(self, other): return True ... Py> hash(C()) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: unhashable instance Py> class C(object): ... def __eq__(self, other): return True ... Py> hash(C()) 10357232
Guido wanted to fix this by eliminating object.__hash__, but that caused problems for Jython. If I remember that discussion correctly, the problem was that, in Jython, the default hash is _not_ simply hash(id(obj)) the way it is in CPython, so Python code needs a way to get access to the default implementation. A hashtools.default_hash that worked like the current object.__hash__ would seem to provide such a spelling, and allow object.__hash__ to be removed (fixing the above bug).
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
