parallel for loops

[Ryan Lowe]

maybe its just me, but the behavior of parallel lists in for loops seems
backwards. why doesnt it mirror parallel assignment? i think tuple-unpacking
should take precedence, but instead iteration happens along the first
dimension and unpacking comes second, forcing the use of zip.

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
use .items() anyway (another thing that should be default in my mind). of
course, using zip is no big deal but im just curious, from a design
perspective why the choice was made.

[Paramjit Oberoi]

>>>> 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)

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.

[Ryan Lowe]

> 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... ;)