On Fri, Jul 26, 2019 at 08:41:40PM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > The hashability requirement for sets is, in a sense, an implementation
> > detail. It might be a requirement for sets in Python the language,
> > but its not a requirement for abstract "sets of values".
> >
> > In this case, they need to be multisets, since
> >
> > {'a': 1, 'b': 2, 'c': 1}.values() != {'a': 1, 'b': 2, 'c': 2}.values()
>
> They don't *need* to be multisets. I would want a comparison of
> values views to be a comparison of images as sets in many cases.
Under what circumstances would you expect two unordered collections of
values:
{1, 2, 3, 1, 1, 1}
{1, 2, 3, 2, 2, 2}
to compare equal? And do you really want that to be the default
behaviour that everyone gets? Remember, too, we don't want the behaviour
of values views to be too different from the behaviour of dicts, keys
and items.
I'm not saying that there's no possible scenario where we might want
that. But it's probably going to be pretty specialised, and probably
not suitable as the general purpose default behaviour.
Ideally the average Python programmer should say "yeah, that behaviour
makes sense", without having to follow it up with "... provided you have
a degree in quantum chromodynamics and the data you are comparing
represents solitons in a quark-gluon plasma".[1]
Analogy: sometimes I want to do clock arithmetic, where 15 == 3, but
that doesn't mean that I want int.__eq__ to default to clock arithmetic
for my (occasional) benefit and everyone else's inconvenience.
> On
> the other hand, if I'm asking if two random variables have the same
> distribution, I would want a comparison of multisets. And for
> stochastic processes, I'd want a list, not a multiset. (Sorry for the
> technical jargon, there are probably similar examples from other, more
> realistic domains.)
Comparisons as ordered sequences are easy:
list(d1.values()) == list(d2.values())
Sets are trickier, because the values might not be hashable, but
depending on your data this could work:
set(d1.values()) == set(d2.values())
I don't think it adds much insight to the problem to discuss all the
wide variety of specialist comparisons we might want to do in narrow
circumstances.
[...]
> > Let's start with the minimal change we have suggested: that two views
> > should be considered equal if they both belong to the same dict.
> >
> > assert d.values() == d.values()
> >
> > Currently that assertion fails. Should it? Putting aside the convenience
> > of "do nothing, just inherit the object.__eq__ behaviour" do you think
> > that the current behaviour is *correct*?
>
> No, I don't. Do you think the proposed behavior (extending equality
> to views of the same dict, and only that) is *useful*?
It's *less wrong* than the current behaviour i.e. it gets the comparison
correct more often, even if it too sometimes returns False for values
which people would expect to compare equal.
[1] Any relationship between what I said and real physics is purely a
coincidence :-)
>
> Steve
>
>
>
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7ZNFSXNMJPLUK7VH7KTCL5K4MPGREYXF/
