Hi, I can't believe we've gone this far:
s = set("a") t = list("aa") s.issubset(t) True s.issuperset(t) True
In *some* sense they are equal:
[demonstration elided]
I don't know that this is an *important* sense, but the OP Steve J isn't wrong to notice it.
Not wrong to notice, but we already have s <= set(t) s >= set(t) s == set(t) as well as s < set(t) and s > set(t), and even set(s) == set(t) etc., where *both* s and t are arbitrary iterables. There's no point to a special method to use for iterables, because you have to decide to use that method based on knowing something is an iterable but not a set. If you're forced to decide to use a special method[1], you can also decide to coerce to set, because set() already accepts an arbitrary iterable. "Explicit is better than implicit" rules in this case, I think. If you don't have special methods, you are generalizing existing set methods to arbitrary iterables, which gives such gems as (the actual Python code, not pseudo-code for "equivalent") assert set("a") == list("aa") but presumably assert not (list("a") == set("aa")) which is horrible on so many levels, mathematical and otherwise. The only possible argument I can see is performance. But even this isn't completely obvious (for worst-case), since I suppose that the iteration to compare two sets is very fast, I would guess a memcmp, while the membership tests needed would be equivalent to constructing the set (i.e., deduplication). On average you get somewhat better performance by short-circuiting when the membership test(s) fail, I suppose. Footnotes: [1] Note that if "s.issubset(t)" is made to behave differently from "s <= t", that's a special method by my definition because you must decide which is appropriate in any given comparison.