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 | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org _______________________________________________ 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
