> 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. IMO it's no odder than disallowing dicts as dict keys: it's a hack that allows a much faster implementation. > 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4