> > > [Ping]
> > > dict[key] = 1
> > > if key in dict: ...
> > > for key in dict: ...
> "Tim Peters" <tim.one@home.com>
> "if (k, v) in dict" is clearly useless...
> 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.
[Greg]
Quick poll (four people): if the expression "if a in b" works,
then all four expected "for a in b" to work as well. This is
also my intuition; are there any exceptions in really existing
Python?
> [Guido]
> for key in dict: ... # ... over keys
> for key:value in dict: ... # ... over items
[Greg]
I'm probably revealing my ignorance of Python's internals here,
but can the iteration protocol be extended so that the object
(in this case, the dict) is told the number and type(s) of the
values the loop is expecting? With:
for key in dict: ...
the dict would be asked for one value; with:
for (key, value) in dict:
the dict would be told that a two-element tuple was expected,
and so on. This would allow multi-dimensional structures
(e.g. NumPy arrays) to do things like:
for (i, j, k) in array: # please give me three indices
and:
for ((i, j, k), v) in array: # three indices and value
> [Guido]
> for index:value in list: ... # ... over zip(range(len(list), list)
How do you feel about:
for i in seq.keys(): # strings, tuples, etc.
"keys()" is kind of strange ("indices" or something would be
more natural), *but* this allows uniform iteration over all
built-in collections:
def showem(c):
for i in c.keys():
print i, c[i]
Greg
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