[Tim Peters] > The docs for __hash__ still spell out the *intent*: [...] > >> What means a "mutable type" then? > It's gotten more <wink> confused. [...] I wondered, earlier today, if we are not documenting this all upside down. (Just wondering, please: I hope nobody will get upset! :-) Python cannot really enforce immutability in the general case, despite it does enforce it for some built-in types. Immutability is a fuzzy concept which represents an *intent*, as you say, and a lot of effort is spent around it in the documentation, trying to remove the fuzziness. > If a class does not define a __cmp__() method it should not > define a __hash__() operation either; if it defines __cmp__() > or __eq__() but not __hash__(), its instances will not be usable > as dictionary keys. 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) Maybe the documentation should also state that `__hash__()' ought to be constant for the full duration of the life of an object. (Is this true? Martin almost says this in his reply. Is there a meaning or reason for a varying hash value for a given object?) Moreover, this might yield an interesting optimisation if not done already: an instance might compute its hash only once, either at creation time, or probably better, lazily until first needed -- but I'm getting away of what I would like to say. Things might be clearer if Python was first and clearly documenting the required properties of `hash()', and then sorting types into hashable (those having such a function) and non-hashable (those not having it). An only then, introducing immutability and mutability as useful user concepts that could be implemented by making objects hashable or not. Then, the documentation could stick to "hashable" and "not hashable", which are very precisely defined, and carefully and systematically avoid "immutable" and "mutable", which are more fuzzy. I have the impression that the net result would be that things would be clearer: tuples are hashable, lists are not; dictionaries require hashable keys. Objects having `__cmp__' (or `__eq__') loose their default hashability. Etc. -- François Pinard http://www.iro.umontreal.ca/~pinard
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4