"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> 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__.
True. I think we ought to leave the behavioral requirements up to the
__hash__ docs, as it's already there. We can use hashable that way,
and maybe define it by implication:
Any object for which hash() returns an appropriate value(1) can be
used as a dictionary key/set element. Lists, sets and dicts are not
hashable, and can not be used. Tuples can be used if all the things
they contain are hashable. instances of all other builin types can be
used. Instances of most classes written in Python can be used(2).
1) See the __hash__ documentation for details on what an approriate
value is.
2) Instances that have a __hash__ method that returns an appropriate
value can be used. Instances that don't have a __cmp__ or an __eq__
method can be used even if they don't have a __hash__ method.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
