The author did not say "as a string" and I am extremly confused as to how you read it like that... what? Essentially, the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented (and you are horribly tempted to play extremely insane tricks with decorators to build something that feels like a Frankenstein Ruby block); this is why the author then brings up arrow functions: it has nothing to do with strings.

> the complaint (which is extremely common) is that functions that contain statements are not expressions in Python, so functional coding styles using things like .map() and .reduce() end up fragmented

You mean these critics find

    >>> map(lambda x: x**2, filter(lambda x: not x % 2, range(11)))

preferable to the "fragmented":

    def square(x):
        return x ** 2

    def is_even(x):
        return not x % 2

    >>> (square(x) for x in range(11) if is_even(x))

Both result in the same lazy iteration (to see results below - requires materialization with a constructor like list or tuple), but I find the "fragmented" approach much more readable (so long as the functions do what their name says they do - I have seen Python where they actually did the opposite...)

    >>> list((square(x) for x in range(11) if is_even(x)))
    [0, 4, 16, 36, 64, 100]
    >>> list(map(lambda x: x**2, filter(lambda x: not x % 2, range(11))))
    [0, 4, 16, 36, 64, 100]

But your lambda example would be more clear if collections functions supported chaining. You can add a small comment if you want to be explicit. This way the code reads linearly, you don't have to wonder why a "square" function and "is_even" function are defined before you see how they are used.

    # square even numbers
    range(11)
      .filter(lambda x: not x % 2)
      .map(lambda x: x ** 2)

However such a chaining API is not practical in python, because lambda syntax is voluntarily crippled to one expression only.

Long method chains are impractical in Python because of the line continuation rules. That's orthogonal to the question of whether complex functions should be required to have names.

There are a few gotchas but you can do it. Mostly you need to put you multi-line chain call inside parentheses if it is not already inside a function call or data structure (similarly to generator expressions).

For example I often end up doing:

    something(
        "Template string {thing}"
        .format(thing=33)
    )

It's possible but rarely more concise or clear than just using variables.

    label = "Template string {thing}".format(thing=33)
    something(label)

I guess it is a matter of preference at some point.

Storing each step in variables has the advantage to be self-documenting and nicer when debugging. However in many cases I feel like wasting energy trying to find short and adequate variable names for each steps in a computation, especially when the steps are clear enough by themselves but difficult to describe in 1-2 short words.

You also need to keep the variable names in sync when refactoring, which may cause even more refactoring if the line gets too long with the new name.

IMO it makes sense to use both styles where they feel most adequate.

Programmers are terrible at naming things and we copy each other's mistakes.

In the real world you filter water to get the water. In most programming languages filter() is more like a strainer or colander.

My guess is you ran into someone stubbornly insisting on the meaning of the word filter despite all evidence.

Well truth be told it was hard for me to understand what the author meant. Thanks for clarification.

I'm guessing, since the author used the arrow shorthand notation in Javascript as an example, that the limitations of Python's lambdas are the chief complaint

It's more of a feature than an arbitrary limitation I think. Python philosophy, 'explicit over implicit', and that stuff.

An intentional limitation, then :P

I tend to agree with the Python philosophy, that it's usually better to extract and name a function that to declare it inline. The `asyncio` module and `await` keywords go a long way in eliminating most use cases where I'd still prefer an anonymous function, for arbitrary callbacks.

I cant figure out what he means either since he follows it up talking about map() and reduce() whcih you can use with function pointers (references? IDK what they actually are in python)

I edited my post, as after giving it some thought I concluded that the author wants to pass around the source code of the function. That indeed is something that python cannot provide in cases when function is already precompiled.

Higher order functions maybe? Though python has them. Spread operator can be done as unpacking a list. Destructuring assignment can also be done. Map is already there while reduce is in functools stdlib. So are all the other functional stuff. Async is in python 3.

Can't say what python lacked except being able use same language on front end and back end. Except if he still uses python 2 which hasn't any new features in years.