hi, if you have a new-style class,
it will have a __hash__ method, even if you don't define it, because it inherits from object(). and, if you implement __eq__, then that default-hash-value will be probably wrong. i understand that this is a bug, and described here: http://www.python.org/sf/660098 but please look at the documentation about __hash__ here: http://docs.python.org/ref/customization.html it says: ==== If a class defines mutable objects and implements a __cmp__() or __eq__() method, it should not implement __hash__(), since the dictionary implementation requires that a key's hash value is immutable (if the object's hash value changes, it will be in the wrong hash bucket). ==== now, with new style classes, the class will have __hash__, whatever i do. (well, i assume i could play with __getattribute__...). so is that part of the documentation currently wrong? because from what i see (the bug will not be fixed), it's still much safer to define a __hash__ even for mutable objects (when the object also defines __eq__). gabor -- http://mail.python.org/mailman/listinfo/python-list
