[Python-Dev] Re: Re: Sets: elt in dict, lst.include
Mon, 29 Jan 2001 13:19:21 -0500
> > > [Ping]
> > > dict[key] = 1
> > > if key in dict: ...
> > > for key in dict: ...
> "Tim Peters" <firstname.lastname@example.org>
> "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
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
> for key in dict: ... # ... over keys
> for key:value in dict: ... # ... over items
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
for ((i, j, k), v) in array: # three indices and value
> 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
for i in c.keys():
print i, c[i]