[Python-Dev] Dict constructor

[Tim Peters]

[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.