First I don't see how naming a function '_' translates into calling it a lambda. Also, i18n much? Doesn't like this def handle_click(self): foo = self.

First I don't see how naming a function '_' translates into calling it a lambda. Also, i18n much? Doesn't like this def handle_click(self): foo = self.flim() if foo: self.flam(foo) onClick(handle_click) And thinks this mess is better with onClick(): def _(self): foo = self.flim() if foo: self.flam() My problems with 2nd include 1) it's ugly, convulted and I'd argue misusing with, 2) by no longer having a name for flimflamfunc you loose documentation, 3) hard to reuse flimflamfunc, 4) hard to decorate, mock, dynamically replace flimflamfunc. Author's main dislike about first code block is "we're required to define the function body before the place where it will be actually used." Which I think is preferable but accept that's my opinion. They're ways to solve that which are easier, cleaner, and more pythonic than author's proposed solution. def callback(onFoo): def inner(func): onFoo(func) return func return inner @callback(onClick) def handle_click(self): pass There might be good reasons for multi-line lambdas, but I don't see any presented here. And if we assume multi-line lambdas are awesome, this is not an acceptable implimentation.