Moshe Zadka writes: > I totally agree with Guido -- for me, the whole point of this hack is > to avoid people asking for 'in' in dicts: this way we can code a class That's not a good enough reason to add it. > I'm not quite sure where we want to put the C API version of __contains__ > - I'd add a tp_as_set, but the only method seems to be 'in', so it seems > like a waste of valuable real-estate before we are driven into > non-backwards-compatability. I think I should at least ask permission from > the owner before I move over there, trampling everything in my way<wink> I suspect there will be fairly few set implementations in C; there will be something like a dictionary (kjSet might be updated, for instance), but that's probably about it. The "in"/"not in" operation can work off the contains slot, and I expect set union would be expressed as +, which is already in the as_number structure. Everything else should probably be implemented as a method or a function rather than as an operator overload. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
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