[Python-ideas] Fwd: Why do equality tests between OrderedDict keys/values views behave not as expected?

[Franklin? Lee]

On Thu, Dec 17, 2015 at 4:34 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Thursday, December 17, 2015 11:50 AM, Franklin? Lee <leewangzhong+python at gmail.com> wrote:
>
>> > On Thu, Dec 17, 2015 at 11:57 AM, Andrew Barnert <abarnert at yahoo.com>
>> wrote:
>>
>>>  * since all mapping keys and items act like sets (and are Sets), they
>> probably compare like sets
>>
>> .items() aren't like sets. Or something is very wrong.
>
> Yes they are. Look at the library documentation for dict and dict views in stdtypes, and in collections.abc. An items view is supposed to be set-like, and to be actually usable as a set if the values are hashable. (If the values aren't hashable, obviously most set operations are just going to raise.) And, as far as I can tell, nothing is very wrong.

Hm.

    >>> x = {0: []}
    >>> y = {0: []}
    >>> x == y
    True
    >>> x.items() == y.items()
    True

That last one doesn't seem set-like to me. But it seems I
misunderstood what you were saying.

Looking at the source code for ItemsView, "containment" is defined as
"other[0] in self and self[other[0]] == other[1]". So yes, it's
set-like, in that it checks for containment. I've just never thought
about "containment of a key => value mapping". (It's funny, 'cause
I've tried to develop the exact same idea in a different subject.)


>>>>  1. OrderedDict().values() does not implement __eq__. It uses object
>>>>  equality, which means identity.
>>>>  1a. dict().values() does not implement __eq__.
>>>>
>>>>  2. OrderedDict().keys().__eq__ does not respect order.
>>>>
>>>>  I'd argue that keys() should be ordered comparisons, and values()
>>>>  could be.
>>>
>>>  So what happens when you compare the keys, items, or values view from an
>> OrderedDict against the view from another mapping type? Or, for keys and items,
>> against another set type? If you leave that up to the whichever one is on the
>> left, you get cases where a==b and b!=a. If you leave it up to the most derived
>> type (by the usual __rspam__-like rules), that doesn't help anything, since
>> dict_keys_view and odict_keys_view are unrelated except in sharing an abstract
>> base class. And, worst of all, even if you contrive a way for one or the other
>> to always win consistently, you get cases where a==b and b==c and a!=c.
>>
>> If OrderedDict views raised NotImplemented, I believe the other view
>> will then have the chance to try its own comparison.
>
> Yes, but the proposal here is for OrderedDict and its views to implement something sequence-like, not to raise NotImplemented, so why is that relevant?

I mean for them to raise NotImplemented in the case of "the other dict
is not an instance of OrderedDict".



Anyway, this is all a moot point. *If* they were to do something
different from dict's views, then they should follow
OrderedDict.__eq__.



PS: To extend "is an OrderedDict a sequence?" in the wrong direction,
I'll point out that OrderedDict.sort(key=None) has a clear and natural
meaning, and the implementation should be obvious (relative to a given
ODict implementation), for either a linkedlist or array ordering. And
to go even further: OrderedDict.items().sort(key=None) also makes some
sense. (Though why you would want to compare with respect to
values...)