On Fri, Dec 18, 2015 at 10:28:52PM -0500, Franklin? Lee wrote:
On Fri, Dec 18, 2015 at 9:34 PM, Steven D'Aprano email@example.com wrote:
On Fri, Dec 18, 2015 at 08:37:09AM -0800, Guido van Rossum wrote:
ValuesView is not a set because there may be duplicates. But the identity thing feels odd. (Even though I designed this myself.) Maybe because values may not be comparable?
Right, that makes sense now, and it's even documented that value views are not treated as sets:
I'm not sure what you mean by "values may not be comparable"? Since we're only talking about equality, aren't all values comparable?
See my example in the other email (https://mail.python.org/pipermail/python-ideas/2015-December/037498.html). That's a case where the order of comparison matters, so you can't do a conceptual "unordered comparison" without, in the worst case, comparing everything to everything else. This is due to custom __eq__ (by OrderedDict, for irony's sake): a == b and b == c does not mean a == c.
I don't know what Guido means by "values might not be comparable", but your example is lack of transitivity.
Mathematical equality is transitive: if a == b, and b == c, then a == c. But that doesn't extend to non-numeric concepts of equality, e.g. preference ordering, or other forms of ranking. Since Python __eq__ can be overridden, we cannot assume that equality of arbitrary objects is necessarily transitive. And indeed, even with Mappings they are not:
py> from collections import OrderedDict as odict py> a = odict([('a', 1), ('b', 2)]) py> b = dict(a) py> c = odict([('b', 2), ('a', 1)]) py> a == b == c True py> a == c False