On 4/21/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > 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 don't understand. Why does the default hash method need to be stored in a location? Why couldn't it be a method on PyObj or whatever their base object it? Or are you talking about a place to store the hash *value*? But why would that need to be stored? > 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. Actually it would significantly reduce the errors because Hashable.__hash__ is abstract, *forcing* you to redefine it. My concern is more with the amount of broken code if we remove object.__hash__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
