>Yes, you're right. Being mutable and hashable are orthogonal properties. >The implication > mutable => non hashable >is just a design choice. > >The reason for such a choice is the following. If a key-element pair K:X >is added to a container C and then K is changed by some external Python >code without letting C know of this change, C may become inconsistent. >Some containers (e.g. set) assume that K=X and just take X. Modifying X >is equivalent to modifying K in the example above. >These kinds of problems are avoided if mutable objects can't be keys. >Some containers require that keys be hashable, but since, by design, >mutable objects can't be keys, there's no reason for them to be hashable >either. > >Kiuhnm
Well, if worst comes to worst and you wind up in a programming situation where you needed to make a mutable object as a hash entry, it's still possible to subclass the object type and have __hash__() return the object's ID instead, right? I can only think of a few edge cases where that could even possibly be required though, such as membership testing for something and having a callback associated with each set of members... ~Temia -- When on earth, do as the earthlings do. -- http://mail.python.org/mailman/listinfo/python-list
