I can't believe we've gone this far:
s = set("a") t = list("aa") s.issubset(t)
In *some* sense they are equal:
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, 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")
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:  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.