Indeed, I noted that (in a not-obvious endnote). Perhaps I shouldn't have mentioned the issue at all as its relatively secondary, but on the other hand while my main points have to do specifically with KeysView, it would be worth bundling all of the inconsistencies in all MappingViews at once, if only for pragmatic reasons.

In the prior discussion, guido also seemed open to making values equivalent on dictionary identity equality (#10), which I think makes more sense than current behavior and doesn't suffer performance issues. In any case, I would consider that a secondary concern.

On Wed, Apr 6, 2016 at 8:50 AM Random832 <random832@fastmail.com> wrote:

On Wed, Apr 6, 2016, at 05:38, Joshua Morton wrote:
> {}.keys() == {}.keys() # 7
> {}.items() == {}.items() # 8
> {}.values() == {}.values() # 9
> d = {}; d.values() == d.values() # 10
>
> True, True, False, False.
>
> Numbers 1, 2, 4, 5 are expected behavior. 3 and 6 are not, and 7-10 is up
> for debate.[1]

Last time this came up, the conclusion was that making values views
comparable was intractable due to the fact that they're unordered but
the values themselves aren't hashable. Then the discussion got
sidetracked into a discussion of whether the justification for not
having them be hashable (Java does just fine with everything being
hashable and content-based hashes for mutable objects) makes sense in a
"consenting-adults" world.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/