> 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.)
IME this limitation just leads to throwaway names like
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...)