[ruszki]

With my solution, you don't need to adapt... that's the whole point. There is no inversion.

[necovek]

It is focused on communication flow for small data-only loops: it is much easier to reason about

  items = [ this for iterator ]

because you immediatelly see what type of data ends up in `items`. Syntax inversion overhead is very much paid for with this benefit IMO.

Again the bigger problem is the 'if', including in comprehensions.

[ruszki]

> you immediatelly see

But that's simply not true at all.

Let's start with token by token:

  items

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.

[necovek]

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.