[PEP202 listcomps] (was RE: [Python-Dev] List comprehension syntax (Features for Python 2.0))

[Tim Peters]

[MAL, on /F's complaints about
    [for x in range(100): x*2]
]
> ...
> IMHO, the meaning of the differen parts is intuitively
> understandable from the fact that Python's standard "for"
> notation works in the same way.
>
> OTOH, the notation "x*2 for x in range(100)" looks strange to me
> and probably to others too, because it doesn't make clear what "x"
> really refers to until you read on... this is Python not Forth or
> Haskell !

The feature is taken from Haskell, which in turn adapted it from SETL.  Both
follow the long-established ordering of mathematical set-builder notation,
where the *expression* is leftmost.  It's the expression that's important,
not the incidental details of the iterators -- there's more than a century
of user experience behind that <0.6 wink>.

I'll note that everything "looks strange" the first time you see it.  It's
more important that it feels right after you grasp it.  That's the case
here!  When I see

    [x**2 for x in range(100)]

I (being a left-to-right reader) immediately grasp "ah, it's a list of
squares".  Write it

    [for x in range(100): x*2]

and it's simply harder to grasp (indeed, *that* "looks strange" to me -- it
looks like somebody started to write a "for" loop and made a typo).

In any case, this particular point was debated to death more than a year
ago, and Guido already Pronounced on it.

> ...
> Note that we could also extend the above by allowing multiple
> such constructs separated by commas:
>
> data = (1.3, 1.2, 1.1)
> l = [for x in data: 3*x,
>      for x in data: x/10]

Sure, and we could write

    u[...]

for Unicode lists too <wink>.  I see no advantage in the above over the
simpler construct, i.e.

   l = [3*x for x in data] + [x/10 for x in data]

except that it may be easier for a dirt-dumb implementation to optimize the
former.