Guido van Rossum wrote:
> I do see your point though: object.__hash__ makes it possible to use
> all sorts of objects as dict keys by default, as long as they don't
> implement __eq__. But perhaps this is not such a good idea and we
> should just get rid of it and add __hash__ back to specific objects
> that are useful to use as keys? (E.g. classes but not iterators, to
> take some extreme examples.)
We've tried to do this before - the point where we got stuck was the
fact that Jython needed a separate location to store the default hash
method (unlike CPython, Jython's id() and object.__hash__() do different
things), and we couldn't come up with a reasonable location for it.
I agree that moving the default method from object to Hashable doesn't
eliminate the errors that arise from redefining __eq__ without
redefining __hash__, but at least it restricts them to those classes
which have Hashable somewhere in their MRO.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
