Steven D'Aprano writes:
The hashability requirement for sets is, in a sense, an implementation detail. It might be a requirement for sets in Python the language, but its not a requirement for abstract "sets of values".
In this case, they need to be multisets, since
{'a': 1, 'b': 2, 'c': 1}.values() != {'a': 1, 'b': 2, 'c': 2}.values()
They don't *need* to be multisets. I would want a comparison of values views to be a comparison of images as sets in many cases. On the other hand, if I'm asking if two random variables have the same distribution, I would want a comparison of multisets. And for stochastic processes, I'd want a list, not a multiset. (Sorry for the technical jargon, there are probably similar examples from other, more realistic domains.) So I think I'm in David's camp (from __future__ import <CAEbHw4aZ--0t32ORbzVYb4PgYjFNN2=P9ooW_XPDxp-Yv=sY2w@mail.gmail.com>): we should inherit __eq__, and if we do anything more, we should provide functions that either do the comparisons correctly (i.e., generalizing set and multiset to non-hashable values), or very efficiently.
Let's start with the minimal change we have suggested: that two views should be considered equal if they both belong to the same dict.
assert d.values() == d.values()
Currently that assertion fails. Should it? Putting aside the convenience of "do nothing, just inherit the object.__eq__ behaviour" do you think that the current behaviour is *correct*?
No, I don't. Do you think the proposed behavior (extending equality to views of the same dict, and only that) is *useful*? Steve