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())
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 | ncoghlan at email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4