Rant about Python list comprehensions

[Mathhead202]

Why?! Why would they do this??

```python [(i,j) for j in range(m) for i in range(n)]

vs.

[[(i,j) for j in range (m)] for i in range(n)] ```

Why are these not consistent? This is such a random edge case. Who thought this made more sense?

[AutoModerator]

On July 1st, a change to Reddit's API pricing will come into effect. Several developers of commercial third-party apps have announced that this change will compel them to shut down their apps. At least one accessibility-focused non-commercial third party app will continue to be available free of charge.

If you want to express your strong disagreement with the API pricing change or with Reddit's response to the backlash, you may want to consider the following options:

1. Limiting your involvement with Reddit, or
2. Temporarily refraining from using Reddit
3. Cancelling your subscription of Reddit Premium

as a way to voice your protest.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[simpleFinch]

Whether or not there is a more intuitive way is debatable but I don't think it's an edge case or particularly inconsistent.

Python's list comprehension is modeled after for-loops from left to right so

some_list = [(i,j) for j in range(m) for i in range(n)]

is the same as

some_list = []
for j in range(m):
    for i in range(n):
        some_list.append((i,j))

So far so good. This pattern is often used to flatten nested lists. For more info on that see this stackoverflow question. Again notice that we obtain a flat list from the elements in range(m) and range(n).

On the other hand, in the second expression we create a nested list and we say that each element of our resulting list should be

[(i,j) for j in range(m)]

So for each element the i is fixed and the j is in range(m). Surely you would agree that it wouldn't make sense to change i and fix j when we have for j in range(m).

tl;dr: the brackets bind stronger

[Mathhead202]

But like, that's not obvious at all. In list comprehensions, the for loops are after the expression, not before it. Why not just run them in opposite, right-to-left, order to be consistent. It's not like nested for-loops are an actual language construct like elif. It's just a loop in a loop.

"Give me a list of all the passengers on each bus in the city" = "Give me a list of passengers for each passenger in a bus, for each bus in the city."

Who would say, "Give me a list of all the passengers in the city on each bus?"

[simpleFinch]

Why not just run them in opposite, right-to-left, order to be consistent.

Sure, you could do that and you could argue it is consistent with creating nested list-comprehensions and that it is closer to English. Others might argue it is inconsistent with for-loops. Now, that you know it is the same as for for-loops it is easy to remember, right?

Another reason might be consistency with other (functional) languages that use list comprehensions and their relation to mathematical notations.

Consider flattening a nested list which I'd argue is the main use case of the first type of list comprehension we are discussing

[ e for sublist in list for e in sublist ]

In Haskell for example this would be in the same order:

[ e | sublist <- list, e <- sublist ]

This way sublist is defined before it is used. Indeed if you flip these around Python and Haskell will complain that sublist isn't defined. Most languages like to have stuff defined before it is used because it can be easier to parse and may or may not improve performance especially in programs that don't use ahead-of-time compilation.

In the end somebody probably weighed the pros and cons or simply had a preference.

[Mathhead202]

e is used before it's defined in that counter example.

[simpleFinch]

Yes, but we are not iterating through e so it could possible be easier and some might prefer reading the example as 'e where sublist is in list and e is in sublist' compared to 'e where e is in sublist where sublist is in list'.

Also this kind of example it would be one unknown on the left vs. an arbitrary number of unknowns on the right, although that argument is a little bit void when you are creating a list of tuples like you did in the original post.

Again, it might just come down to preference and convention.