Michael Foord wrote:
> This may have been true for old style classes, but as new style classes
> inherit a default __hash__ from object - mutable objects *will* be
> usable as dictionary keys (hashed on identity) *unless* they implement a
> __hash__ method that raises a type error.
>
> Shouldn't the advice be that classes that implement comparison methods
> should always implement __hash__ (wasn't this nearly enforced?), and
> that mutable objects should raise a TypeError in __hash__.
Hmm, I thought I fixed those docs when I did the
PyObject_HashNotImplemented patch... (you can set __hash__ = None rather
than raising a TypeError explicitly now so that collections.Hashable
correctly returns False - the slot machinery in typeobject.c will then
take of turning that into PyObject_HashNotImplemented at the C level).
However, looking at the relevant checkins, it appears I only updated the
C API docs and didn't correct the library or language references.
I reopened http://bugs.python.org/issue2235 - there are some other doc
fixes I need to do this weekend for RC1, so I can tackle this at the
same time.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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