A single, non-nested list comprehension or generator exp is basically map(filter). You need nesting to get filter(map).
e.g.
map(expensive_call, filter(cond, seq))
equals
[expensive_call(each) for each in seq if cond(each)]
but
filter(cond, map(expensive_call, seq))
equals
[each for each in [expensive_call(x) for x in seq] if cond(each)]
note because of "expensive_call", it's inefficient (and silly) to do
[expensive_call(each) for each in seq if cond(expensive_call(each))]
So map/filter combination gives more flexibility than list comprehension, and for functional-thinking minds, it's just so natural to think in abstract terms of passing functions around. List comprehension is pretty syntactical sugar to do similar things, but it forces you think about the "how to do" instead of "what to do".
That said, it's not really "compelling" though -- there is no real "compelling" reason to switch from one Turing-complete language to another given that you can do the same thing eventually. But hey, it's the itches that drive us nuts, isn't it? :)
Just my 2 cents
e.g.
equals but equals note because of "expensive_call", it's inefficient (and silly) to do So map/filter combination gives more flexibility than list comprehension, and for functional-thinking minds, it's just so natural to think in abstract terms of passing functions around. List comprehension is pretty syntactical sugar to do similar things, but it forces you think about the "how to do" instead of "what to do".That said, it's not really "compelling" though -- there is no real "compelling" reason to switch from one Turing-complete language to another given that you can do the same thing eventually. But hey, it's the itches that drive us nuts, isn't it? :)
Just my 2 cents