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/