[Guido]
... Let's do a set module instead. There's only one hurdle to take for a set module, and that's the issue with using mutable sets as keys. Let's just pick one solution and implement it (my favorite being that sets simply cannot be used as keys, since it's the simplest, and matches dicts and lists).
I want a set module, but if I finish Greg's abandoned work I want sets of sets too. Sets don't have "keys", they're conceptually collections of values, and it would be as odd not to allow sets containing sets as not to allow lists containing lists, or to ban dicts as dict values. Greg needed sets of sets for his work, and I've often faked them too. I'm not going to be paralyzed by that combining mutable sets with sets of sets requires that some uses of set-as-set-element will be expensive, fragile, and/or hard to explain. If you don't want that pain, don't play that game. If you do want sets of sets, though, and aren't willing to live with a purely functional (immutable) set type, it's non-trivial to implement correctly -- I don't want to leave it as a term project for the reader. There's also the Zope BTrees idea of sets of sets:
s1 = OISet() s1 = OISet(range(10)) s1.keys() [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] s2 = OISet([5]) s2.keys() [5] s1.insert(s2) 1 s2 in s1 1 OISet([5]) in s1 0
That is, like sets of sets in Icon too, this is a notion of inclusion by object identity (although Icon does that on purpose, while the BTree-based set mostly inherits it from that BTrees don't implement any comparison slots). That's very easy to implement. It's braindead if you think of sets as collections of values, but that's what taking pain too seriously leads to.