[issue2235] __eq__ / __hash__ check doesn't take inheritance into account

Nick Coghlan report at bugs.python.org
Sun Jun 29 10:34:34 CEST 2008


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Well, I think I figured out why the __hash__ changes were backported
from Py3k: without them, the existence of object.__hash__ makes the
Hashable ABC completely useless (every newstyle class meets it).

I see two options here. Option 1 is to revert the changes so __hash__
behave entirely as it did in 2.5 and also delete collections.Hashable
from 2.6 (which may break other backported Py3k items). Doesn't seem
like a particularly good idea.

Option 2 is what I have implemented locally (and will be uploading
soon): changing typeobject.c to allow Py_None to be stored in type
method slots, and have it convert correctly to None at the Python level.
Classes that don't want to inherit the default object.tp_hash
implementation can then write "__hash__ = None" or "(hashfunc)Py_None"
to block the inheritance.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
_______________________________________


More information about the Python-bugs-list mailing list