Securing a future for anonymous functions in Python
bokr at oz.net
Fri Dec 31 01:31:45 CET 2004
On Thu, 30 Dec 2004 15:15:51 -0800, Jeff Shannon <jeff at ccvcorp.com> wrote:
>David Bolen wrote:
>>>I think this specific use case -- defining callbacks -- should be
>>>addressed, rather than proposing a solution to something that isn't
>>I'd be interested in this approach too, especially if it made it simpler
>>to handle simple manipulation of callback arguments (e.g., since I often
>>ignore a successful prior result in a callback in order to just move on
>>to the next function in sequence).
>It seems to me that what most people *actually* want, when asking for
>lambdas, is a quicker and more convenient way to get closures. (At
>least, that's what the vast majority of examples of lambda use seem to
>be for.) Perhaps one could get a bit more traction by looking for
>improved closure syntax instead of focusing on the anonymous function
Not sure what you mean by closure here. To me it means the necessary
external environment needed to be captured for use by a function definition
getting exported from its definition environment. I.e., it is something
a function uses, and part of the function definition, but it isn't the
function itself. I would compare a closure more to a callable class instance's
self attributes, except that the latter are more flexible.
In fact, for a callback, a constructor call creating a suitable
callable class instance could sometimes work well as a substitute
for a lambda expression, ISTM. (I.e., when it is not important to
show the code in line, and the differences are in initialization parameters
rather than code).
>All of the suggestions for anonymous multiline functions (with embedded
>indentation) seem to me to miss what seems to me to be the only
>significant benefit of lambda -- its ability to be used in-line without
>creating a huge ugly tangle. (I'd argue that lambdas create a *small*
>ugly tangle, but apparently that's just me. ;) ) Lambdas do have some
>value in defining callbacks, but that value derives almost exclusively
>from the fact that they are in-line (rather than a few lines above).
They do let you define _code_ inline, which a constructor call doesn't do
(unless you pass a string to compile etc -- not cool).
>Mimicking function-def indentation inside of another function's arglist
>strikes me as an abomination just waiting to happen; in comparison, the
>need to type a name twice seems trivial.
Self-restraint can avoid abominations ;-)
>As a result, it seems to me that, rather than generalize lambdas into
>"full" anonymous functions (with most of the negatives and few of the
>positives of lambda), it would be much better to specialize them further
>into inline-closure-creators, where they can serve a valuable purpose
>without quite as much risk of code pollution.
There's always the temptation to be enforcer when being persuader
is not the easiest ;-)
(BTW, again, by closure, do you really mean deferred-action-thingie?)
More information about the Python-list