Steven D'Aprano wrote: > On Wed, Jul 24, 2019 at 05:30:19PM -0000, Brett Cannon 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 > 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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/K3SYX4DER3WAOWGQ4SPKCKXSXLXTIVAQ/
