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