Enhanced Python Syntax: Implicit zip() function

I propose introducing a new syntax for looping over two iterables simultaneously:

for i, j in a, b:
    # do something with i and j

Current State:

As it stands, when we need to iterate over two lists (or other iterables) in parallel, we typically use the zip function:

for i, j in zip(a, b):
    # do something with i and j

While this approach is perfectly functional, I believe a more direct and readable syntax could improve the clarity and elegance of the code.

Rationale:

  1. Readability: The proposed syntax directly reflects the intention of iterating over two collections in parallel without the need to mentally parse the zip function. This can be particularly helpful for beginners or when quickly scanning code.

  2. Conciseness: The proposed syntax is shorter and eliminates the need for an additional function call, making the code cleaner.

  3. Consistency: Python strives for readability and simplicity. Enhancing the for loop syntax in this manner aligns well with Python’s philosophy.

Example Comparison:

Current syntax with zip:

a = [1, 2, 3]
b = ['a', 'b', 'c']

for i, j in zip(a, b):
    print(i, j)

Proposed syntax:

a = [1, 2, 3]
b = ['a', 'b', 'c']

for i, j in a, b:
    print(i, j)

Both snippets would produce the same output:

1 a
2 b
3 c

Considerations:

  • Backward Compatibility: This proposal does not break existing code since it introduces a new syntax.
  • Implementation: The underlying implementation would essentially translate the new syntax to the existing zip(a, b) construct.

I am keen to hear your thoughts and feedback on this idea. Do you think this enhancement would be beneficial? Are there any potential pitfalls I haven’t considered?

Looking forward to a constructive discussion.

by the way, it the first time I post on python forum, please notice me if I am offending any rule.

It doesn’t; the syntax you propose is already valid. (It iterates over a tuple.)

>>> a = (1, 2)
>>> b = (3, 4)
>>> for i, j in a, b:
...     print(i, j)
...     
1 2
3 4
7 Likes

what about making for i,j in (a,b) iterates over a tuple but for i,j in a,b calls implicit zip() function? Besides, the existing usage of for i, j in a, b as iterating over a tuple is relatively rare.

I have often done something like this:

for name in "spam", "ham", "foo", "bar":

sometimes with, sometimes without, parentheses. So, no, that’s still not going to fly. As a general rule, if something is currently valid syntax, you can assume that there is code out there in the wild that uses it. That means, if you’re going to change its meaning, you have to have a VERY good reason - something a lot more than just removing the need to call zip() on the arguments.

5 Likes

I can see the attractiveness of this.

If there was only one way to do it (or if it was the case that python only allowed zipping only iterables of equal size) then having special syntax for it might be sensible.

However, there are many ways to do it: zip, zip_longest, zip_broadcast, …

Having special syntax only for zip does not seem justified to me.

2 Likes

so use zip() function as default?

This is currently a syntax error:

for (i in a, j in b):
    ...

BTW, if you’re looking for previous discussions about this, search for “lockstep iteration”.

2 Likes

Are there any other languages (especially popular ones) that have dedicated syntax for parallel iteration? In any sort of proposal like this, it’s highly informative to see what has already been done elsewhere. That’s not to say that a proposal can’t fly if nobody else has ever done it (see “many things must be done, but nothing must be done for the first time” from Yes Minister), but that would itself be extremely informative (WHY has nobody else done this? Just that nobody has yet thought of it?).

Are you seriously suggesting all the work that goes into enacting and supporting a syntax change, and the implementation of for loops, is justified to save programmers typing the 5 characters zip()?!

This would make code less readable, and potentially more confusing. The current option you seek to replace, is in keeping with “explicit is better than implicit”. And even if a new Python user doesn’t know what it does, the zip built-in is easily discoverable.

3 Likes

I don’t think it’s obvious that this would or should mean for i, j in zip(a, b) instead of for i, j in product(a, b).

Regarding readability, even if this wasn’t valid syntax already, it’s not obvious that it couldn’t mean for i, j in chain(a, b): rather than for i, j in zip(a, b):.

1 Like

Just answering Chris’ question (and not supporting or going against the OP proposal), The Zig programming language does this, see For loops | zig.guide . AFAIK (I know very little) there’s no zip function in Zig.

1 Like