parallel for loops

Discussion in 'Python' started by Ryan Lowe, Apr 27, 2004.

  1. Ryan Lowe

    Ryan Lowe Guest

    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.
    Ryan Lowe, Apr 27, 2004
    #1
    1. Advertising

  2. >>>> 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.
    Paramjit Oberoi, Apr 28, 2004
    #2
    1. Advertising

  3. Ryan Lowe

    Ryan Lowe Guest


    > >>>> 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... ;)
    Ryan Lowe, Apr 28, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Soren
    Replies:
    4
    Views:
    1,236
    c d saunter
    Feb 14, 2008
  2. Vivek Menon
    Replies:
    5
    Views:
    3,311
    Paul Uiterlinden
    Jun 8, 2011
  3. Vivek Menon
    Replies:
    0
    Views:
    1,748
    Vivek Menon
    Jun 10, 2011
  4. Me
    Replies:
    2
    Views:
    229
  5. Peter Valdemar Mørch

    Proposing a new module: Parallel::Loops

    Peter Valdemar Mørch, Jun 22, 2010, in forum: Perl Misc
    Replies:
    11
    Views:
    189
    Ted Zlatanov
    Jun 29, 2010
Loading...

Share This Page