New docs for set elements/dictionary keys

"Martin v. Löwis" martin at
Sun Nov 27 23:52:06 CET 2005

Mike Meyer wrote:
>>>Personally, I think we'd be better off to come up with a term for this
>>>property that doesn't have a commonly understood meaning that has such
>>>broad areas of disagreement with the property. I've been using
>>>"hashable", which I would currently define as "has a __hash__ method
>>>with the properties described in the __hash__ documentation, or does
>>>not have either a __cmp__ or a __eq__ method."
>>I would like to use "hashable" as a term as well, but it appears that
>>many people would understand that to mean "has a __hash__
>>implementation" (i.e. hash(x) returns a value, instead of raising an
> Well, the two aren't quite the same thing: hash returns a value on
> some things that don't have a __hash__. But that is close to the
> meaning I want to give it. What meaning did you have in mind?

Me, personally, I had your definition in mind: hashable should indicate
"returns a value constant over time and consistent with comparison".

I suggested that most people would consider "hashable" to mean:
hash() returns a value. To those people, it is a minor detail whether 
you get the fallback implementation of hash() or whether there is a
default __hash__ implementation for all objects that don't otherwise
define __hash__.


More information about the Python-list mailing list