On 07.07.20 19:41, Stephen J. Turnbull wrote:
Dominik Vilsmeier writes:> Well, the point is that this "except comparisons" is not quite true: > > >>> i = {'a': []}.items() > >>> s = {('a', 1)} > >>> i == s > TypeError: unhashable type: 'list' > > If passed a set as `other` operand, dict_items seems to decide to > convert itself to a set, for no obvious reasons since, as you > mentioned, it does know how to compare itself to another view > containing non-hashable values: The obvious reason is that they didn't want to implement the comparison if you didn't have to, the dict.items() view is a Set, so the obvious implementation is s == set(i). > So if you're dealing with items views and want to compare them to a set > representing dict items, then you need an extra `try/except` in order to > handle non-hashable values in the items view. Sounds like you have a change to propose here, then. Put the try/except in the __eq__ for the items view class when comparing against a set. I would expect it to be accepted, as comparing items views is pretty expensive so the slight additional overhead would likely be acceptable, and if you get the exception, you know the equality comparison against a set is false since a set cannot contain that element, so this possibility can't affect worst-case performance by much, if at all.
Exactly, this seems like it would come at a small cost, and preventing this TypeError during equality testing seems definitely worth it.
> Surely [dict.values equality comparison having object equality > semantics] must be a relic from pre-3.7 days where dicts were > unordered and hence order-based comparison wouldn't be possible > (though PEP 3106 describes an O(n*m) algorithm). However the > current behavior is unfortunate because it might trick users You mean "users might trick themselves". We provide documentation for exactly this reason.
Correct, and the Python docs are very good. But given the amount of StackOverflow questions which are well covered by the docs, it seems that users often go by their intuition when they encounter new situations. The dict_values __eq__ might be one such scenario. But I understand that any other implementation has to make its own assumptions, so the current situation is fine (it's probably a rare use case anyway). _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7THLTDPJKGPJ5ZW4SB72OQDBL6DNN6YM/ Code of Conduct: http://python.org/psf/codeofconduct/
