Let's Talk About Lambda Functions!

[Bengt Richter]

On Sun, 4 Aug 2002 11:17:35 -0400, "Steve Holden" <sholden at holdenweb.com> wrote:

>"John Roth" <johnroth at ameritech.net> wrote ...
>> "Steve Holden" <sholden at holdenweb.com> wrote ...
>[ ... ]
>> > Mostly because anything as complicated as this current proposal is
>> more
>> > complicated than defining a named function and using it the once.
>> Frankly
>> > (IMHO), anything that need this much explanation is unlikely to find
>> its way
>> > into Python.
>>
>> Taking account of Tim Peter's comments on 7/29, I think you're
>> right that Guido is unlikely to approve it. Nontheless, it's been an
>> interesting conversation to get my head straight on how it should
>> look in Python, if it was ever approved.
>>
>I'm glad it's been helpful.
>
>> And at this point, it's incredibly simple, not complicated. When the
>> compiler sees the token sequence: 'left paren,' 'indent,' 'def' it
>> shifts to compiling an anonymous function, including the indentation
>> rules. When the function ends, it shifts back to whatever it was
>> doing before. I fail to see what is complicated about that.
>>
>...if we overlook the minor detail that the "indent" token can only occur at
>the beginning of a line. I don't mean to beat this to death, but in order
I don't think he meant indent after the paren without a newline, unless he
meant as an implicit use of that line's already established indent to wherever
its first non-blank is. But forcing use of a newline before the indent to the def
would be good stylistically. OTOH, it wouldn't seem that hard to take the
column number of the 'd' in the 'def' as defining a single indent to the 'def'
and going from there. Normal usage for style would be to use expression-within-paren
freedom and place the def nicely on the next line in any case.

Suppose you defined a new atom expression in the grammar that would be matched
before '(' [testlist] ')' in (this is old 2.1 grammar)
    atom: '(' [testlist] ')' | '[' [listmaker] ']' | '{' [dictmaker] '}' | ...
e.g.,
    atom: '(' anonydef ')' | '(' [testlist] ')' | ...
where
    anonydef: 'def' parameters ':' suite

noting that
    suite: simple_stmt | NEWLINE INDENT stmt+ DEDENT


>for your proposal to work you have to alter the syntax of expressions to
>make indentation significant where it currently isn't. That's a) far from
>trivial, and b) far from obvious.
But not insurmountable either, I would think.

>
>> The actual implementation needs to take care of those messy details
>> of real world syntax, but it's still not complicated.
>>
>You believe. I'm still wondering how you can measure the indentation level
>of a token that isn't the first non-whitespace token on its line, and how
>you can verify that subsequent lines have "the same" indentation.
To simplify (and prettify) let's assume the def _is_ on a new line. How would
processing it and its indented suite differ from normal def processing (except
for resulting in an anonymous function value instead of binding it to a name)?

>
>There's probably some detail of your proposal that I'm missing, but I really
>do believe it's dead in the water. You could produce a PEP, that at least
>would have the merit of making your proposal (and the reasons for its
>rejection, should it be rejected) fully explicit.
>
Probably the only thing that would give it a snowball's chance would be to have
a working patch along with the PEP, and some really clean examples of usage,
and of course ZERO breakage ;-) Breakage would seem relatively easy to avoid, though,
since 'def' can AFAIK never occur legally after '(' in pre-PEP code. BTW, that's
a reason to have mandatory parens, unlike lambda.

Regards,
Bengt Richter