Why do you have to call items() to iterate over key, value pairs in a dictionary? ie.
dic = {\'one\': \'1\', \'two\': \'2\'}
for k, v in dic.items():
pri
My guess: Using the full tuple would be more intuitive for looping, but perhaps less so for testing for membership using in
.
if key in counts:
counts[key] += 1
else:
counts[key] = 1
That code wouldn't really work if you had to specify both key and value for in
. I am having a hard time imagining use case where you'd check if both the key AND value are in the dictionary. It is far more natural to only test the keys.
# When would you ever write a condition like this?
if (key, value) in dict:
Now it's not necessary that the in
operator and for ... in
operate over the same items. Implementation-wise they are different operations (__contains__
vs. __iter__
). But that little inconsistency would be somewhat confusing and, well, inconsistent.
For every python container C, the expectation is that
for item in C:
assert item in C
will pass just fine -- wouldn't you find it astonishing if one sense of in
(the loop clause) had a completely different meaning from the other (the presence check)? I sure would! It naturally works that way for lists, sets, tuples, ...
So, when C
is a dictionary, if in
were to yield key/value tuples in a for
loop, then, by the principle of least astonishment, in
would also have to take such a tuple as its left-hand operand in the containment check.
How useful would that be? Pretty useless indeed, basically making if (key, value) in C
a synonym for if C.get(key) == value
-- which is a check I believe I may have performed, or wanted to perform, 100 times more rarely than what if k in C
actually means, checking the presence of the key only and completely ignoring the value.
On the other hand, wanting to loop just on keys is quite common, e.g.:
for k in thedict:
thedict[k] += 1
having the value as well would not help particularly:
for k, v in thedict.items():
thedict[k] = v + 1
actually somewhat less clear and less concise. (Note that items
was the original spelling of the "proper" methods to use to get key/value pairs: unfortunately that was back in the days when such accessors returned whole lists, so to support "just iterating" an alternative spelling had to be introduced, and iteritems
it was -- in Python 3, where backwards compatibility constraints with previous Python versions were much weakened, it became items
again).