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. 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.)
So I think I'm in David's camp (from __future__ import
<CAEbHw4aZ--0t32ORbzVYb4PgYjFNN2=P9ooW_XPDxp-Yv=s...@mail.gmail.com>):
we should inherit __eq__, and if we do anything more, we should provide
functions that either do the comparisons correctly (i.e., generalizing
set and multiset to non-hashable values), or very efficiently.
> 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*?
Steve
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/Q54ENOKPCS3XYHK2BPR72462YQT2REEA/