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