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

[Antony Lee]

2013/10/24 Stephen J. Turnbull <stephen at xemacs.org>

> 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.
>

I think you've misunderstood the aim of my proposal.  While my proposal
does contain the possibility, as a syntax extension, to define anonymous
lambdas (or functions, if you prefer), in the middle of an expression (as
opposed to "in a statement"), the core idea is about *named* lambdas (or
functions, etc.).  From the very beginning I said that allowing the
anonymous form ("(def (...): ...)" instead of "(def name(...): ...)") was
not a critical part of the proposal.


>
>  > 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").
>

I was specifically referring to Andrew Barnaert's reply, which I quote here:

Partly this is based on JS experience, where you have to write .bind(this)
> all over the place because your callback--or, worse, some callback later in
> the chain--needs access to this.
>

Specifically, I was asking his to clarify the relevance of such an issue as
a locally defined lambda (etc.) already captures "self" without the need
for a call to a JS-like bind (which is effectively spelled __get__ in
Python).


> 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.


No, that is not what I complain about.  Just look at the other currently
active thread on context manager semantics, where Nick Coghlan said

it *also* means that we *don't* currently have a clean syntax for single
> use callbacks.
>
> Hence the time I've put into PEP 403 and 3150 over the years - a key
> objective for both of them is providing a cleaner solution for the problem
> of single use callbacks (including those that modify local variables of the
> containing function).
>

Another example is when you want to provide a dictionary of callbacks (e.g.
to be triggered by various command line options), say at global scope,
without putting the callbacks themselves in that scope).   See Serhiy
Storchaka's suggestion on why multiline lambdas are not essential here:

> callbacks = {
> >      "foo":
> >          (def foo():
> >              <...>), # note how the parentheses disambiguate where the
> > last comma belongs
> >      "bar":
> >          (def bar():
> >              <...>)
> > }
>
> def class_to_map(cls):
>      return {n: f for n, f in cls.__dict__items() if n[0] != '_'}
>
> @class_to_map
> class callbacks:
>      @staticmethod
>      def foo():
>          ...
>      @staticmethod
>      def bar():
>          ...
>

I don't think abusing the class statement is particularly elegant either
(and good luck if you want to preserve order... what, I have to provide a
metaclass that overrides __prepare__ for doing this?), and moreover this
solution doesn't even work as it is written (it needs a small fix... quick,
can you spot it)?


> Steve
>

Antony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20131024/529574fa/attachment.html>