[Python-Dev] Proposal for a module to deal with hashing

Nick Coghlan ncoghlan at iinet.net.au
Sat Feb 19 05:46:32 CET 2005

Gregory P. Smith wrote:
> 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())

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).


Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia

More information about the Python-Dev mailing list