I sing the praises of lambda, my friend and savior!

[Bengt Richter]

On Mon, 11 Oct 2004 22:29:11 -0000, Dave Benjamin <ramen at lackingtalent.com> wrote:

>In article <10mlsct69hmtgca at corp.supernews.com>, Jeff Shannon wrote:
>> gabriele renzi wrote:
>>>
>>> then what you want is a better lambda. One where you can use return, 
>>> maybe, and  where you can have statements and multiple expressions.
>>> Don't throw away the baby with the bathwater.
>> 
>> But because of Python's line- and indentation-based syntax, doing all of 
>> that on a single line is... um... awkward at best, to put it mildly.  
>
>This is true. I think that Ruby's code block syntax offers a workable
>alternative. Many will dispute this, saying it's too ugly, but this is
>subjective and not based on any technical reasons. Here is what I've
>proposed in the past:
>
>def with_open_file(filename, proc):
>    f = open(filename)
>    try:
>        proc(f)
>    finally:
>        f.close()
>        
>with_open_file('data.txt', {|f|
>    for line in f:
>        print line
>})
>
>This is nearly identical to Ruby's syntax, except that instead of creating
>an object with a call method, it creates a callable.
>
How about extending lambda? E.g.,

 with_open_file('data.txt', lambda f:<
     for line in f:
         print line 
 >:) 

I.e., the first non-white-space after the initial ':<' defines suite indentation,
and a corresponding (to allow nesting) '>:' closes the lambda body (without necessarily
having to be out-dented). Hence you could do a one liner for the above example:

 with_open_file('data.txt', lambda f:< for line in f: print line >:) 

IMO, if you are familiar with lambda,

    lambda f:< ... >:

is less of a jump than

    {|f| ... }

What did I forget? ;-)

Obviously
    lambda f:expr
can also be spelled
    lambda f:< return expr >:

>> And once you make a lambda multiline, then you lose most of the point of 
>> it -- at least, as far as I understand what the point is (having an 
>> in-line, anonymous callable).  Once you allow statements and multiple 
>> expressions, all you're gaining is anonymity, which seems like a pretty 
>> paltry benefit to me.
>
>It's not so much the anonymity that matters, it's the ability to use them as
>expressions. It allows you to create your own control structures without
>disrupting the logical flow of your program. For instance, right now in
>Python you'd have to write the above like this:
>
>def doit(f):
>    for line in f:
>        print line
>
>with_open_file('data.txt', doit)
>
>To me, this reads, "When I say 'doit', I mean iterate through each line in
>some given object 'f', and print that line. Now, with the open file, 'doit'."
>Whereas, in the previous example, I'm saying, "With the open file, for each
>line in the file, print the line." The difference is subtle, perhaps, but
>the need to define a named function beforehand rearranges my code in a way
>that I'm not particularly fond of.
I agree.
>
[...]
>I actually discovered lambdas in Python first (well, technically Tcl, but I
>didn't know it at the time), and since then I have done a lot of programming
>in Python. In fact, it would be safe to say that Python biases my use of
>other languages to a greater degree than any other language biases my use of
>Python. I don't use lambdas very often, but their use does come up, and I
>would rather see them become more powerful (or see code blocks added to the
>language) than have them be removed entirely. I'd like to see a ternary
>operator too. Guido would have probably added one by now, but nobody could
>agree on which syntax would be most "Pythonic". The same fate, I fear, is in
>store for any sufficiently advanced anonymous function syntax in Python.
>
>(Yet, somehow, decorators slipped through, even though nobody agreeed on a
>syntax for that either. I don't have a rational explanation for that...)

Maybe we can piggyback on that ;-)

    @lambda f:<
        f.__name__ += '_decorated_by_an_extended_lambda'
        return f >:
    def foo(): pass
    
Regards,
Bengt Richter