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

[Stephen J. Turnbull]

Antony Lee <anntzer.lee at gmail.com> writes:
>>>>> 2013/10/24 Stephen J. Turnbull <stephen at xemacs.org>

 > I think you've misunderstood the aim of my proposal.

No, I misunderstood the language in your most recent post, not to
mention the consistent mis-specification of the whole idea in *every*
subject line.  Python doesn't currently have a notion of "binding"
lambdas to objects, and you here don't specify how a lambda (object)
is being "bound" to what (other kind of) object.  Python does have a
notion of binding names to objects.  Confusion is natural.

If you're *primarily* talking about defining functions in the "right
place" in general, what's wrong with using the well-defined Python
terms for those objects?

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

Sure.  So there is no "need" in the first place.  I don't understand
what you're talking about.  IMO Nick's use case, described next, is
compelling.  Why not just say "this syntax does the trick for that use
case"?  Are you saying anything else?  That's what I can't figure out.

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

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

Eh, "there you go again."  That's the same example, isn't it?  It's a
good one and stands repeating, but it's not different.  In both cases
you have a callback and a desire to put the def in an appropriate
"place" (namespace, and often lexical position in the source).  The
dictionary of callbacks idiom is familiar (at least to those of us to
have the misfortune to program with Xt), and I certainly understand
the desire to define callbacks in an appropriate scope.  Again, do you
have *more* to say than "I think my syntax does this nicely,
concisely, and precisely"?

If you have other compelling use cases, that would be useful.  But I
think the "defining callbacks in the right place" use case would be
enough to get this proposal in Python 3.5 (if it stands up to issues
like the LL constraint on the languages, and the objection to
YAAP[1]).  Mixing this up with "lambda" and "binding" is unhelpful
AFAICS.

 > 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?),

I doubt you need to use a metaclass (storing the callbacks in an
OrderedDict and then defining an appropriate __index__ can probably be
done with a decorator or two), but the alternatives are hardly
prettier I guess.


Footnotes: 
[1]  Yet Another Abuse of Parentheses, also spelled "YAAPMILL"
("... Making It Like LISP").