I find Python's list comprehensions unusable because they're backwards from how I'd expect. Thankfully in Scala the syntax is almost exactly the same; you write

    for {
      a <- list1
      b <- list2
    } { do something}

for an imperative for loop, and

    for {
      a <- whatever1
      b <- whatever2
    } yield { ... }

for the general comprehension. In Python you have to put the equivalent of the yield right at the start, which is just so different from how everything else in the language works.

Whoever designed the comprehension syntax for Python was perhaps enamored of the "such that" math notation { expr-with-vars | constraint-predicates }.

https://en.wikipedia.org/wiki/Set-builder_notation#Sets_defi...

I wish they'd leave the math notation as is. Haskell's and Erlang's notations which keep it (maybe with slight modifications) are so much nicer and readable.

Erlang [1]:

    [X || X <- [1,2,a,3,4,b,5,6], X > 3].

    Pythagorean triplets

    [ {A,B,C} ||
        A <- lists:seq(1,N),
        B <- lists:seq(1,N),
        C <- lists:seq(1,N),
        A+B+C =< N,
        A*A+B*B == C*C 
    ].

[1] http://erlang.org/doc/programming_examples/list_comprehensio...

That's because Python's list comprehensions were derived from Haskell's implementation: https://wiki.python.org/moin/PythonVsHaskell#List_Comprehens...:

As per https://wiki.haskell.org/List_comprehension , many Haskell users prefer to use do syntax (indeed I wasn't aware that the list comprehension syntax existed).

Agreed, I never use list comprehensions in Haskell. I feel like they're almost always harder to read.

That's an interesting point I had not thought of before. For me, it does not make them unusable, but tastes differ. Also see my sibling comment.

Don't understand why people don't like nested for-loops. I love list comprehensions, but I honestly would not consider one and abstraction, generalization, or improvement of the other.

Python list comprehensions (at least IME) are not that complicated or incomprehensible, at least up to two levels of nesting, with say one if clause, maybe even two. In fact, the language designers even took care (for the sake of comprehensibility :) to ensure that the two fors (in a two-level nested listcomp) have the same meaning (aka order of priority) as a two-level nested for loop, i.e. outer for wraps inner for, in both cases. It's mentioned in the spec somewhere.

> In fact, the language designers even took care (for the sake of comprehensibility :) to ensure that the semantics of the two fors (in a two-level nested listcomp) have the same meaning (aka order of priority) as a two-level nested for loop, i.e. outer for wraps inner for, in both cases. It's mentioned in the spec somewhere.

Yeah, I think that was a huge mistake, because the most common case is one-level and if you have one level the syntax is just the reverse of a regular for, but in a two-level comprehension (the rare case) you have to remember that it's not a reversal, it's a cyclic permutation.

i.e. most of the examples you see look like this, and these two are equivalent:

    [y for i in x]
    for i in x: y

and then occasionally you see a comprehension that looks like:

    [z for j in y for i in x]

so you'd expect this to be equivalent to

    for i in x: for j in y: z

but it isn't, it's equivalent to

    for j in y: for i in x: z

which is really hard to remember.

Hadn't thought of it that way myself, I may have just thought that the way (order) it works is the same as the way it is actually designed to work, and then later looking at the docs confirmed that, but yes, yours is a valid point of view.

Agreed, the sheer usefulness and joy of having a legible stack trace with the ability to set debug points is invaluable.