parallel for loops

Ryan Lowe ryanlowe0 at msn.com
Wed Apr 28 18:33:44 EDT 2004


> >>>> a, b = [1,2,3], [4,5,6]     # a = [1,2,3], b = [4,5,6]
> >>>> for a, b in zip([1,2,3], [4,5,6]): print a, b
> >
> > instead of:
> >>>> for a, b in [1,2,3], [4,5,6]: print a, b     # illegal
> >
> > im sure there is a good reason why the former was chosen, and i know its
way
> > too late to switch, but i cant think of many examples of when you would
use
> > parallel iteration *without* zip. not even dictionaries since you have
to
>
> dates = [(2004, 4, 27), (2004, 2, 9), (2003, 11, 14)]
> for year, month, day in dates:
>     do_something_with(year)
>     and_with(month, date)

i assume you meant day instead of date on the last line...

> Also, it's more consistent: in each iteration, an element of the
> list being iterated over is assigned to the loop variable; or if
> it's multiple variables, automatic unpacking happens just like it
> would if a value were assigned to multiple variables in an
> assignment statement.

i had thought of something like that, say points:

for x, y, z in points:

but when i really stopped to think about it, it is not more consistent since
(x, y, z) is not a direct member of the points list; its a decomposition of
a single point. likewise, (year, month, day) is a single date. therefore you
should have to say:

for point in points:
   x, y, z = point
   ...

its one more line, but its more explicit. or just use a point class and
access point.x, point.y, and point.z. i guess it comes down to whether
breaking up a single list of tuples is the more common use of parallel
iteration vars, or iterating over multiple iterators with a single var each.
i think its the latter, but maybe thats just the type of problems ive
encountered that dealt with parallel iteration...

as another example, the old problem of including the counter var, only
/satisfactorily/ solved by enumerate(). this is a case where i have to stop
and remember which comes first the counter or the contents. of course, its
still a lot better than the hideous old solution:

for i, v in zip(range(len(list), list):

removing the zip helps a bit (using my logic), and its clear which part goes
to which which var:

for i, v in range(len(list), list:

then if you had a function that returned the indexes of a list, its very
clear and only a couple of characters longer than enumerate, without the
order problem:

for i, v in indexes(list), list:

anyway its just something to think about, or maybe waste time thinking
about... ;)






More information about the Python-list mailing list