I would argue that multi-line anonymous functions are unpythonic. Exhibit A is this line from PEP 20:
Readability counts.
I'm currently about a month into learning a legacy codebase that was written in a functional language. If I could single out one thoroughly egregious practice that has made this code far, far more difficult to read and understand than it should have been, it's multi-line anonymous functions. In general, if a function is doing something complicated enough to need multiple lines of code, it's doing something complicated enough to merit an explicit name.
> if a function is doing something complicated enough to need multiple lines of code, it's doing something complicated enough to merit an explicit name.
def foo_and_bar(x):
foo(x)
bar(x)
whew! good thing i named that
IME this limitation just leads to throwaway names like
process(x)
go(x)
do_foo(x) # in foo(x)
cb/callback/fn
because a lot of things just don't have sensible names! just like how it'd suck to have to come up with a name for every loop body
(although there was some book advocating for "replace every loop body with a named function" so some people enjoy that i guess...)
I see you chopping the first two words off that quote. ;)
In this specific case, that single instance of a single pattern is such a throw-away that it doesn't deserve a name, but the pattern itself is easy enough to name. So I'd skip the single-purpose function and create a combinator.
def do_each(*args):
def helper(x):
for fn in args:
fn(x)
return helper
and then, when I need to do both foo and bar, I don't even need a lambda.
map(do_each(foo, bar), some_sequence)
That's a fairly specific case, though. Moving back to the general, I would say that a function that does more than one thing, but can't easily be named, is a code smell.
Of course, every general rule has its exceptions. But I'm not so keen on the idea of optimizing one's coding style for the exceptional cases. Going back to PEP 20, "Special cases aren't special enough to break the rules."
(I realize mapping a function that returns nothing is terrible, but I'm feeling too lazy to think of a better example.)
i like a nice combinator as much as the next person! but consider this: if python already had multiline lambdas, would you be arguing for using a narrow-purpose combinator instead of `lambda x: foo(x); bar(x)`?
[this kind of reminds me of Go's generics mess, where workarounds for lack of generics are "just how you write Go and that's the language's philosophy"... until generics land and suddenly they won't be]
Probably. I think the former is more readable and, at the use site, more concise.
Regardless, I don't think the hypothetical is super useful, because its unstated major premise is, "But what if we, for the sake of argument, ignore all the other good reasons why Python doesn't have them?"
My favorite programming language is functional, and has significant whitespace and multiline anonymous functions. While it is my favorite, I do have to concede that the Python language maintainers' worries about the syntactic implications of multiline lambdas in a whitespace language are accurate.
(I could quote the zen of python some more here, too. Lines 5 and 6.)
Assignment expressions were "unpythonic" based on PEP 20 until they weren't. Modern languages have multi-line anonymous functions, and developer expectations have changed in the 17 years since PEP 20 was published.
