Steven D'Aprano wrote:
When I saw this I thought, "it should be like set(d1.values()) == set(d2.values())", but has been pointed out there's no guarantee that all values will be hashable. 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". E.g. Java includes a standard TreeSet which doesn't require hashability https://docs.oracle.com/javase/7/docs/api/java/util/TreeSet.html In this case, they need to be multisets, since {'a': 1, 'b': 2, 'c': 1}.values() != {'a': 1, 'b': 2, 'c': 2}.values() After that I have no expectation since order isn't guaranteed. I think this is one of those cases where it's superficially surprising when you don't think about all the ramifications, but once you understand the complexity of the problem then it becomes more clear that it isn't straight-forward. Nobody said it was straight-forward, particularly if we want guaranteed efficient comparisons in both time and space at the same time. Brett, I feel that you are dismissing this thread as "not thinking
On Wed, Jul 24, 2019 at 05:30:19PM -0000, Brett Cannon wrote: through the ramifications" without reading it through, because I'm pretty sure that we have thought through the ramifications in a lot more detail than your dismissal justifies.
Sorry, I didn't explicitly state the perspective to read that statement from. I'm not saying the people participating here don't understand the ramifications which have been brought up (which I have read top-to-bottom). My point is people who are **not** reading this thread may be surprised if they try this (i.e. users out in the wild which was the perspective I meant to convey), but **if** they are brought to understand the complexity required to make their assumption work then I would hope they would understand why things work the way they do.
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?
Yes I do if we aren't going to make this work regardless of actual dict objects because if you don't make this work for `d1.values() == d2.values()` then I think that would make `d.values() == d.values()` more surprising as to why it works in one case where the values were all the same but not in another.
(By correct I mean in the technical sense that if we were writing a functional spec for views, we would actively desire two views of the same dict to be unequal.)
To me a doc update for dict.values() stating that the iterator can't be compared and a brief mention as to why would be the best solution for this. We're not talking about comparing iterators. We're talking about comparing views into a dict. That's a difference that makes all the difference.
You're correct that I misspoke, but I personally still think a doc change is the best solution.