[Python-ideas] Fwd: Why do equality tests between OrderedDict keys/values views behave not as expected?

[Random832]

Andrew Barnert  writes:
> If you're thinking we could define what multisets should do, despite
> not having a standard multiset type or an ABC for them, and apply that
> to values views, the next question is how to do that in better than
> quadratic time for non-hashable values.

Why aren't all values hashable?

When I think about it, it's a bit strange that "hashable" is so
wrapped up in immutability for no other reason than the idea
that it's not safe to use a mutable object as a dictionary key
if it is changed while it is in the dictionary.  Java doesn't
have this restriction.

And while the reasoning is certainly defensible in isolation, it
sort of goes against the "consenting adults" principle that is
used to justify all the _other_ dangerous/questionable things
that Python doesn't bother putting technical obstacles in front
of.

Why not demand that all objects (except NaN?) can be hashed, and
that their hash shall match the equality relationship they
define, and that all objects can safely be used as set members
and dictionary keys so long as they are not in fact changed
while in such a position? Certainly we can't put technical
restrictions in the way of defining a __hash__ method that
raises an exception, but we can say that if they try to use such
an object in a dictionary and compare their values views they're
on their own.

For a somewhat more conservative path forward, define a new
method __vhash__ which will always return a value (by default
based on the object identity), and __hash__ shall return either
the same number as __vhash__, or raise an exception if the
object is not guaranteed as "immutable" for the purpose of
equality comparison.