So when they designed it, it wasn’t that bad for simple cases. However, with more complex nested lists, there isn’t a clear data flow, it jumps from one place to another. Especially the first term is problematic. It’s not beneficial at all for the modern IDE based development. So at the end, this is a better list comprehension in this sense:
`[state_dict.values() for mat to mat2 for row for p to p/2]`
Or similar, where data flow is 1->2->f(2)->3->4->f(4). Where right now it is this lovely mess with one more repeating term:
`[p / 2 for mat in state_dict.values() for row in (mat 2) for p in row]`
Where the flow is f(4)->2->1->3->f(2)->4->3
This is not just a Python list comprehension problem obviously. The simple for… in… has a similar problem. It’s only better, because the first term `p/2` is at the end.
I'm struggling to even understand what you have in mind, because HN doesn't do Markdown formatting and asterisks are interpreted for emphasis across lines. But I've never really thought there was a problem with the syntax. To me it reads naturally, left to right: "A list ([) of the results from calculating whatever, (for) each of the (name) values that are (in) the (names) container". With multiple clauses, they're in the same order as the corresponding imperative code, which also makes sense. (Perhaps if "for" were spelled "where", it might not...)
You seem to be complaining more about for working on iterators/generators like range() and not on comprehensions themselves.
List comprehensions are inverted (syntax-wise) compared to regular program flow, but that is pretty easy to learn and adapt to (and is, imo, much better than "a = b if x else c").
You have no clue what type of data ends up in `items`, or that something should end up in `items` at all. This is obvious.
items =
You have no clue what type of data ends up in `items`. You just know now, that something will end up there.
items = [
You only know that a list will be in `items`. Not what will be in the list.
items = [ this
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.
items = [ this for
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`.
items = [ this for iterator
You only know that a list will be in `items`. Not what will be in the list. You have no clue what is `this`. You cannot have, or you break the right to left propagation with nested cases, against what you have with this simple example of yours.
items = [ this for iterator ]
This is the only time when you know what type is `items` or `this`.
Also `this` is a useless identifier, if you cannot transform or filter in your list comprehension. I don't like mine either that it contains pointless words...
Don't get me wrong, your example is clearly a right to left data flow. Which is not inherently bad, because `items` and `this` are new identifiers, which won't figure out by IDEs, so it doesn't matter.
Also, in my example of Python code (not my version of it, but the valid Python code), there is no need to have `if` at all to break intellisense, or break either left to right or right to left data flow several times inside the list comprehension.
If you named your variables properly and your editor supported type hints, you'd have none of these issues: I used generic names for demonstration.
Compare it to
family_adults = [ person for person in family_members if person.age >= 18 ]
Code should be as readable as possible by default: I'd argue you do not even need types in code with good naming, though they do prove their worth in codebases being evolved for a long time and many people.
`[state_dict.values() for mat to mat2 for row for p to p/2]`
Or similar, where data flow is 1->2->f(2)->3->4->f(4). Where right now it is this lovely mess with one more repeating term:
`[p / 2 for mat in state_dict.values() for row in (mat 2) for p in row]`
Where the flow is f(4)->2->1->3->f(2)->4->3
This is not just a Python list comprehension problem obviously. The simple for… in… has a similar problem. It’s only better, because the first term `p/2` is at the end.