[Python-Dev] Dict constructor

Tim Peters tim.one@comcast.net
Sun, 14 Jul 2002 00:17:00 -0400


[Guido]
> IMO it's no odder than disallowing dicts as dict keys: it's a hack
> that allows a much faster implementation.

Except that sets are an extremely well-developed concept apart from Python,
and you can only go a little way using set-based approaches before sets of
sets are a screamingly natural occurrence.  In that respect, sets that can't
contain sets are akin to limiting integer arithmetic to 32 bits (also a hack
that allows a much faster implementation, but screaming speed just isn't
Python's forte -- this line of argument belongs more in Fortran-Dev).

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

> I don't think it is acceptable to have sets-of-sets but test for
> membership (in that case) by object identity.
>
> If you really think object identity is all that's needed, I suggest we
> stick to disallowing sets of sets; algorithms needing
> sets-of-set-object-identities can use id() on the inner sets.

I called the object identity approach "braindead" for those who think of
sets as collections of values, and I previously identified myself as one of
those suffering the collection-of-values delusion.  You can do the modus
ponens bit from there <wink>.