On 23/03/2020 09:12, Steven D'Aprano wrote:
On Sun, Mar 22, 2020 at 08:55:47PM -0700, Andrew Barnert wrote: [...]
But I don’t think that’s relevant here. You claimed that 'the "arbitrary iterables" part is a distraction', but I think it’s actually the whole point of the proposal. The initial suggestion is that there are lots of iterables that are both a subset and a superset of some set, and only the ones that are sets are equal to the set, and not having a way to test for the ones that aren’t sets is the “missing functionality” that needs to be added for completeness.
Well I'm glad that you got that out of Steve's posts, because I didn't :-)
Assuming you are correct, isn't that easily done with a type conversion?
A == set(B)
We might argue about the inefficiency of having to build a set only to throw it away, but given that there's no real use-case for this (so far), only a sense of completeness, it might be good enough. Or one could do:
A.issubset(B) and A.issuperset(B)
assuming B isn't an iterator.
As far as I can tell, they’re just trying to add a method isequivalent or iscoextensive or whatever that extends beyond == to handle non-set iterables in the exact same way issubset and issuperset extend beyond <= and >= to handle non-set iterables.
If it were a method, set.equals() is the obvious name, since that's what it is actually testing for: set equality, without the conversion to a set.
s = set("a") t = list("aa") s.issubset(t)
but it would be misleading IMO to say that s and t are in some sense equal. Explicit conversion to a set is the right way to compare sets. (Perhaps issubset/issuperset should not accept non-set iterables, but that ship has sailed.) Rob Cliffe