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

[Guido van Rossum]

On Fri, Dec 18, 2015 at 7:57 PM, Steven D'Aprano <steve at pearwood.info>
wrote:

> I don't know what Guido means by "values might not be comparable", but
> your example is lack of transitivity.
>

I mean cases where == actually raises an exception. In Python 2 we did this
for comparing certain 8-bit strings to unicode strings. While we've fixed
that particular issue (in 3, bytes(...) == str(...) always returns False),
it's still possible, and in fact even some stdlib modules do this -- I know
certain comparisons of naive and tz-aware datetimes do this (which is not
the same as returning NotImplemented).

However for full disclosure I should add that until just now I had
misunderstood the complaint about values() -- it doesn't compare the values
by identity, values views themselves are only compared by identity.

But (how's this for a nice recovery :-) that's how comparing dict.values()
works, and it's reasonable given how expensive it would be to make it work
otherwise (the corresponding ABCs behave the same way).

The real oddity is that an OrderedDict's keys and items views don't take
order into account, even though comparing the OrderedDict objects
themselves does use the order. This seems to be laziness of implementation
(just inheriting most of the view implementation from dict) rather than
based on some careful design consideration. Unless I missed the
consideration (I wasn't involved in the design of OrderedDict at all TBH).

(And FWIW if we do fix this I might be amenable to changing the way values
views are compared, but *not* by taking the keys into account. It's either
by identity of the view object, or by comparing the values in order.)

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151218/55dd467c/attachment.html>