[Python-Dev] bool does not want to be subclassed?

[François Pinard]

[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