On Thu, 3 Feb 2000, Fred L. Drake, Jr. wrote: > > 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. Well, it the metaphorical sense it is -- the reason people were asking for 'in' in dicts were usually because they wanted to use dictionaries as sets. Not having a way to express with 'in' certainly seems like a wart. > > 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, I'm afraid I didn't understand you /at all/. Can you just say what is it you're offering? There isn't a "contains" slot right now, and what I'm wondering is where to put it. -- Moshe Zadka <mzadka@geocities.com>. INTERNET: Learn what you know. Share what you don't.
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