I'm sometimes tempted to use it in loops, when

  for x in map(func, iterable):
      ...

is cleaner than

  for x in (func(y) for y in iterable):
      ...

and shorter than

  for y in iterable:
      x = func(y)
      ...

But that mostly only makes sense if you already have a suitable named function (e.g. str), and I usually end up going with the third variant anyway.

There's an analogous case with filter and `if not cond: continue`.

map and filter calls are trivially rewritten to generator expressions, but it's not necessarily an improvement.

Coconut has many examples of functional programming techniques that cannot be easily done with python: https://coconut.readthedocs.io/en/master/DOCS.html

Strangely FP is not popular among python developers.

It's a pain in the ass to write functional code in python because the syntax is not optimized for it. A functional programming language makes lambda and (partial) application as cheap as possible, which Python does not.

I think you can get 95% of the benefit of FP just by favoring abstractions which present a functional interface. Python hasn't really gotten in my way, in that respect, though it would be nice to have first-class persistent data structures with structural sharing.

is coconut used in production? seems like a really bad idea?

It's python after all, so why not?

> What can you do that cannot be as easily done with generator expressions?

Technically nothing, but at the same time if you already have a function (especially a builtin) map/filter is more convenient and can be faster. And they're first-class objects which comprehensions are not, which can be convenient.

The goal is not necessarily to prune all redundancies: reduce already existed when sum/min/max/any/all were added, despite the latter being fairly simple special cases of the former (not quite entirely for min/max, but not far).

Why bother having any control logic other than conditionals and gotos? Because they signal intent directly.