[Niksko]

That seems a little harsh.

Nested list comprehensions with multiple filtering if statements? Scald away.

But the simpler examples there are perfectly readable, understandable and maintainable if you understand list comprehensions. And if you need to alter it to the point where it needs to be a little more verbose in order to convey what you're doing, then sure, you can break it out into some other structure. But just because the complexity might increase later on doesn't mean that you shouldn't use a list comprehension.

[matt_wulfeck]

But what do you gain from using nested list comprehension like that? There's no performance gain (or very, very little). The only tangible benefit I see is saving a few lines of code.

And for those few lines of code you've traded the ability for new programmers to understand it easily. To me that's a net loss.

[Retra]

New programmers should learn how to use list comprehensions. They're not just some obscure Python concept, they appear in multiple other languages, as well as mathematics.

[RodericDay]

It's actually much more sensible code a lot of the time, especially for people who didn't get a degree that consisted of a lot of for-looping in class.

    good_jedis = [jedi for jedi in universe if jedi.alignment == "good"]

vs.

    good_jedis = []
    for jedi in universe:
        if jedi.alignment == "good":
            good_jedis.append(jedi)

And then when you get on stuff like dictionary comprehensions and generator expressions, it starts becoming an amazing tool that is able to accomplish things that are straight-up cumbersome with old loops.

There's a computer science course out there that a friend was telling me about, that begins by showing students how to "map" a function over an iterable, way way before a "for loop" ever shows up. I think this is the way it should be done, "for loops" as a three-line-structure only seem natural to people who grew up programming for loops.

[spamizbad]

for-ins leak iteration variables into the function scope, which can introduce subtle bugs if you're not careful.

set/dict/generator comprehensions do not.

Example:

   for foo in bar:
     baz(foo)
   
   print foo  # Will actually print something

Whereas

   whatever = {baz(foo) for foo in bar}
   print foo # NameError: name 'foo' is not defined

does not put foo into the outer scope.

list comprehensions in python 2 (but not 3) will leak variables however.

[orf]

There is always a performance gain, and sometimes it can be fairly huge.