Mailing List Archive

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