"in" for dicts (was: Python 2.1 function attributes)

[Tim Peters]

[Nathaniel Gray]
> ...
> Nevertheless, there are still three big problems with "in" for
> dictionaries:
>
> Number 1:  There is no reason, a priori, to think that "in dict" should
> mean "in dict.keys()" rather than "in dict.values()" or even "in
> dict.items()".  Explicit is better than implicit, right?

This is the reason Guido gave most often in previous years.  It appears that
only professional debaters *believe* it, though <wink>.  That is, to the
best of my knowledge, nobody ever claimed that they personally would mistake
what

    if x in dict:

or

    for x in dict:

meant.  They're always worred that "somebody else" might not get it.  After
a decade, it's increasingly hard to believe that set of supernaturally
feeble users isn't empty.

> Number 2:  The chosen semantics for "in dict" are inconsistent with the
> meaning of "in" in the context of lists.  The "keys" of a list are the
> integers from 0 to len(the list) - 1.
> ...

But this one he's always dismissed as "hypergeneralization".  He really
doesn't think of lists (or tuples, for that matter) as being a flavor of
mapping.  So arguments based on the belief that they are get rejected.

> Number 5:  (three, sir)  Oh yes, number 3:  We've already got
> "for a_key in dict.keys()"!

We still don't have anything else for 2.1; only "a_key in dict" in a
*boolean* context has been implemented.  And, yes, we've already got
dict.has_key(a_key) for that.  And, yes, Guido just *approved* of adding
"for a_key in dict" too, although implementing that is a puzzle given the
current iteration protocol's use of __getitem__ (it doesn't jibe with what
dict.__getitem__ does), and "what to do" about programs that go mutating the
dict during iteration.

> The only reason we're introducing these ambiguous, inconsistent
> semantics is so that we can use a dictionary as a set and still
> say "for thing in a_set:".

As I said before, Guido didn't appear to have sets in mind at all, and
neither did Ka-Ping Yee over the years he's been suggesting this change.
Ping simply took the recent flurry of "set" discussion as an *opportunity*
to push this change again.  It's been suggested by many others over the
years too, some of whom may never even have heard of sets <wink>.

> (I sure hope we're not doing it just to save a few keystrokes every
> now and then!)

No.  I don't even believe that was mentioned.  Most people seem to think
that these uses of "in" for dicts are *obvious*, and that has been
mentioned -- often.  Some have also mentioned that "x in dict" will be
faster than "dict.has_key(x)", and ditto for iteration (in which latter case
it may also save an unbounded amount of additional storage).  The latter has
been a FAQ for years:

    http://www.python.org/cgi-bin/faqw.py?req=show&file=faq06.012.htp

> We're not straightening out an awkward idiom or clearing up a
> Python wart,

See above.

> we're masquerading one data structure as another.

I don't see that.  Boolean "in" is another name for "has_key", so in that
sense it's nothing new at all.  And as the FAQ entry above explains, Python
already has a dict iterator under the covers, it's simply never been
exposed.

> "It's not a big dog.  Perhaps if we clipped it's ears and taught it to
> meow it could pass for a cat!"

Oh, now I'm getting confused!  Is a dict the dog or the cat?  Is a list the
other one?  And what are the ears?  Is meowing iteration?  In that case
we're taking the cat out of the dungeon and removing the cruel muzzle from
its cute little kitty mouth, while giving the doghouse a fresh coat of
paint.

> Once again, wouldn't it just be better to have a collections module for
> Python with a Set class and let dictionaries be dictionaries?

Sorry, but this really has very little to do with sets.  It's more to make
the crocodiles happy without feeding them household pets.

> And yes, I dislike list.pop() too.  ;^)

Really?  Or did you intend to say you dislike dict.pop() (which would fit
better with the animal analogies <wink>).

> Lest I come off as too much of a grumpy Gus, I should add that I really
> like most of the new stuff in Python 2.1a1, particularly xreadlines.

Figures -- that's the one Guido likes least.  He dislikes xrange too.  He
was forced into xreadlines by timing considerations (we couldn't match its
performance cleanly, not with finite effort).  The only reason to like
xreadlines is speed (which is reason enough!) -- but in that case you should
like both flavors of "x in dict" too, and for the same reason.

> I'll  be first in line to upgrade when 2.1 stabilizes, even if "in dict"
> survives.

Hey, CVS is open for business!  The only way a new release stablilizes is
via people *using* it.  People who wait until the final release to report
bugs are going to have to wait months for relief.  That said, Python alpha
releases have been more stable than most peoples' final releases in my
decade of Python experience, and I'm both surprised and delighted that this
doesn't seem to have changed despite the radical change in development
process last year.  Python is still leading a charmed life that way.

don't-ever-name-a-language-"mongoose"-ly y'rs  - tim