On Thu, Dec 17, 2015 at 4:34 PM, Andrew Barnert abarnert@yahoo.com wrote:
On Thursday, December 17, 2015 11:50 AM, Franklin? Lee leewangzhong+python@gmail.com wrote:
On Thu, Dec 17, 2015 at 11:57 AM, Andrew Barnert abarnert@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.)
- OrderedDict().values() does not implement __eq__. It uses object
equality, which means identity. 1a. dict().values() does not implement __eq__.
- 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...)