now that we have the sq_contains slot, would it make sense to add support for "key in dict" ? after all, if key in dict: ... is a bit more elegant than: if dict.has_key(key): ... and much faster than: if key in dict.keys(): ... (the drawback is that once we add this, some people might ex- pect dictionaries to behave like sequences in others ways too...) (and yes, this might break code that looks for tp_as_sequence before looking for tp_as_mapping. haven't found any code like that, but I might have missed something). whaddyathink? </F>
On Thu, 13 Apr 2000, Fredrik Lundh wrote:
now that we have the sq_contains slot, would it make sense to add support for "key in dict" ?
after all,
if key in dict: ...
The counter has always been, "but couldn't that be read as 'if value in dict' ??" Or maybe 'if (key, value) in dict' ?? People have different impressions of what "in" should mean for a dict. And some people change their impression from one function to the next :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
On Thu, 13 Apr 2000, Greg Stein wrote:
On Thu, 13 Apr 2000, Fredrik Lundh wrote:
now that we have the sq_contains slot, would it make sense to add support for "key in dict" ?
after all,
if key in dict: ...
The counter has always been, "but couldn't that be read as 'if value in dict' ??"
I've been quite happy with "if key in dict". I forget if i already made this analogy when it came up in regard to the issue of supporting a "set" type, but if you think of it like a real dictionary -- when someone asks you if a particular word is "in the dictionary", you look it up in the keys of the dictionary, not in the definitions. And it does read much better than has_key, and makes it easier to use dicts like sets. So i think it would be nice, though i've seen this meet opposition before. -- ?!ng "You should either succeed gloriously or fail miserably. Just getting by is the worst thing you can do." -- Larry Smith
Ping> I've been quite happy with "if key in dict". I forget if i Ping> already made this analogy when it came up in regard to the issue Ping> of supporting a "set" type, but if you think of it like a real Ping> dictionary -- when someone asks you if a particular word is "in Ping> the dictionary", you look it up in the keys of the dictionary, not Ping> in the definitions. Also, for many situations, "if value in dict" will be extraordinarily inefficient. In "in" semantics are added to dicts, a corollary move will be to extend this functionality to other non-dict mappings (e.g., file-based mapping objects like gdbm). Implementing "in" for them would be excruciatingly slow if the LHS was "value". To not break the rule of least astonishment when people push large dicts to disk, the only feasible implementation is "if key in dict". -- Skip Montanaro | http://www.mojam.com/ skip@mojam.com | http://www.musi-cal.com/
Skip Montanaro writes:
Also, for many situations, "if value in dict" will be extraordinarily inefficient. In "in" semantics are added to dicts, a corollary move will be to extend this functionality to other non-dict mappings (e.g., file-based mapping objects like gdbm). Implementing "in" for them would be excruciatingly slow if the LHS was "value". To not break the rule of least astonishment when people push large dicts to disk, the only feasible implementation is "if key in dict".
Skip, Performance issues aside, I can see very valid reasons for the x in "x in dict" to be either the key or (key, value) pair. For this reason, I've come to consider "x in dict" a mis-feature, though I once pushed for it as well. It may be easy to explain that x is just the key, but it's not clearly the only reasonably desirable semantic. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
participants (5)
-
Fred L. Drake, Jr. -
Fredrik Lundh -
Greg Stein -
Ka-Ping Yee -
Skip Montanaro