[Python-ideas] YAML (yet-another-multiline-lambda)

[Andrew Barnert]

On Oct 24, 2013, at 3:10, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:

> Antony Lee writes:
> 
>> as I mentioned earlier I don't really see the need
> 
> It's not a *need*, it's a *style*.  Ie, it's just the way Pythonistas
> do things.
> 
> Many fledgling Pythonistas, especially those who come from other
> languages, hanker after anonymous functions or Ruby blocks (a somewhat
> different concept AFAICT), and some experienced Pythonistas sympathize
> with them.  But there's no real reason why some functions shouldn't
> have a name, and Guido (the ultimate authority on "Pythonic") isn't a
> fan of lambda, so (unless a pressing need or a really good syntax
> appears) there seems to be little chance of the existing feature
> (expressions as lambdas) being extended.
> 
>> for binding lambdas to objects in the first place.
> 
> I think you've misspoken here.  Lambdas *are* objects, and that's why
> names can be bound to them (and then they're called "functions").
> What people complain about is the fact that the normal way to create a
> lambda (callable function object or something like that) is "def",
> which also binds a name to the object.  They think that is wasteful or
> something.

I think the desire for this feature is less about the name issue, and more about two other issues.

The big issue is that you can't put a statement in an expression. Python has a much stricter statement/expression barrier than most languages. Python also has a nice separation between its declarative subset and the rest of the language. And it ties these two things together: composable expressions don't have side effects. All of this contributes a lot to Python's readability. But it can be limiting. If you want to throw a side effect like updating a variable into the middle of an expression--whether it's a listcomp or a lambda callback--you can't. In Ruby, JavaScript, the main .NET languages, and even some of the impure traditional functional languages, doing that kind of thing is not just allowed, but idiomatic. That's why all of these proposals are about a way to embed a statement context (a "multiline lambda" or "inline def") into the middle of an expression.

There's also an order-of-definition problem. You want to put code where it belongs, and to avoid highlighting code that isn't the important part of your logic. When you write a call to async_read() or Button() with a trivial callback, it's easier to understand if the callback is inside the call (which is why we have lambdas in the first place). Nick Coghlan's two @in PEPs are about providing this feature without the previous one (and I think it's significant that they've attracted much less dislike, but also less positive excitement).