> [Ping]
> > dict[key] = 1
> > if key in dict: ...
> > for key in dict: ...
>
> [Guido]
> > No chance of a time-machine escape, but I *can* say that I agree that
> > Ping's proposal makes a lot of sense. This is a reversal of my
> > previous opinion on this matter. (Take note -- those don't happen
> > very often! :-)
> >
> > First to submit a working patch gets a free copy of 2.1a2 and
> > subsequent releases,
>
> Thomas since submitted a patch to do the "if key in dict" part (which I
> reviewed and accepted, pending resolution of doc issues).
>
> It does not do the "for key in dict" part. It's not entirely clear whether
> you intended to approve that part too (I've simplified away many layers of
> quoting in the above <wink>). In any case, nobody is working on that part.
>
> WRT that part, Ping produced some stats in:
>
> http://mail.python.org/pipermail/python-dev/2001-January/012106.html
>
> > How often do you write 'dict.has_key(x)'? (std lib says: 206)
> > How often do you write 'for x in dict.keys()'? (std lib says: 49)
> >
> > How often do you write 'x in dict.values()'? (std lib says: 0)
> > How often do you write 'for x in dict.values()'? (std lib says: 3)
>
> However, he did not report on occurrences of
>
> for k, v in dict.items()
>
> I'm not clear exactly which files he examined in the above, or how the
> counts were obtained. So I don't know how this compares: I counted 188
> instances of the string ".items(" in 122 .py files, under the dist/ portion
> of current CVS. A number of those were assignment and return stmts, others
> were dict.items() in an arglist, and at least one was in a comment. After
> weeding those out, I was left with 153 legit "for" loops iterating over
> x.items(). In all:
>
> 153 iterating over x.items()
> 118 " over x.keys()
> 17 " over x.values()
>
> So I conclude that iterating over .values() is significantly more common
> than iterating over .keys().
I did a less sophisticated count but come to the same conclusion:
iterations over items() are (somewhat) more common than over keys(),
and values() are 1-2 orders of magnitude less common. My numbers:
$ cd python/src/Lib
$ grep 'for .*items():' *.py | wc -l
47
$ grep 'for .*keys():' *.py | wc -l
43
$ grep 'for .*values():' *.py | wc -l
2
> On c.l.py about an hour ago, Thomas complained that two (out of two) of his
> coworkers guessed wrong about what
>
> for x in dict:
>
> would do, but didn't say what they *did* think it would do. Since Thomas
> doesn't work with idiots, I'm guessing they *didn't* guess it would iterate
> over either values or the lines of a freshly-opened file named "dict"
> <wink>.
I don't much value to the readability argument: typically, one will
write "for key in dict" or "for name in dict" and then it's obvious
what is meant.
> So if you did intend to approve "for x in dict" iterating over dict.keys(),
> maybe you want to call me out on that "approval post" I forged under your
> name.
But here's my dilemma. "if (k, v) in dict" is clearly useless (nobody
has even asked me for a has_item() method). I can live with "x in
list" checking the values and "x in dict" checking the keys. But I
can *not* live with "x in dict" equivalent to "dict.has_key(x)" if
"for x in dict" would mean "for x in dict.items()". I also think that
defining "x in dict" but not "for x in dict" will be confusing.
So we need to think more.
How about:
for key in dict: ... # ... over keys
for key:value in dict: ... # ... over items
This is syntactically unambiguous (a colon is currently illegal in
that position).
This also suggests:
for index:value in list: ... # ... over zip(range(len(list), list)
while doesn't strike me as bad or ugly, and would fulfill my brother's
dearest wish.
(And why didn't we think of this before?)
--Guido van Rossum (home page: http://www.python.org/~guido/)
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