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

Nick Coghlan ncoghlan at gmail.com
Fri Oct 25 00:10:59 CEST 2013


On 25 Oct 2013 03:06, "Andrew Barnert" <abarnert at yahoo.com> wrote:
>
> 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).

Right, when people get excited about Ruby's "blocks" and say Python should
have something equivalent, they can actually be talking about two subtly
different things:
- the block statement (do/end) which handles single use callbacks nicely
- inline blocks which let you embed callbacks with side effects on name
bindings in the local namespace inside expressions

The functional programming influence on Python at the expression level is
strong enough for me to say "no, we almost certainly don't want to go
there" (but see the postscript below).

The first would definitely be a nice problem to resolve, though.

Cheers,
Nick.

P.S.
http://python-notes.curiousefficiency.org/en/latest/pep_ideas/suite_expr.html

>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131025/30358b6d/attachment.html>


More information about the Python-ideas mailing list