Securing a future for anonymous functions in Python

[Nick Coghlan]

Paul Rubin wrote:
> "Anna" <annaraven at gmail.com> writes:
> 
>>Having taken some calculus (derivatives, limits, some integrals) but
>>never even heard of lambda calculus, to me, lambda means absolutely
>>NOTHING. Less than nothing.
> 
> 
> Lambda calculus is from mathematical logic, but more to the point
> "lambda" has been the term used in Lisp for this operation since time
> immemorial.

I think that's part of the problem though - people familiar with lambda calculus 
and Lisp's lambdas want Python's lambdas to be equally capable, and they just 
plain *aren't*.

If you have a complex function, the Pythonic way is to give it a meaningful 
name. Having a way to defer evaluation of a simple expression *is* quite handy, 
but 'lambda' is the wrong name for it - the parallels to lambda calculus and 
Lisp's lambda functions are likely to be misleading, rather than helpful.

Add in the fact that there are many, many Python programmers with non-CS 
backgrounds, and the term 'lambda' sticks out like a sore thumb from amongst 
Python's other English-based keywords. 'def' is probably the second-most cryptic 
when you first encounter it, but it is a good mnemonic for "define a function", 
so it's still easy to parse. "Lambda is the term mathematicians use to refer to 
an anonymous function" is nowhere near as grokkable ;)

For me, the alternative syntax discussion is based on 3 of the 4 mentioned reasons:

1. The syntax
   I don't like re-using colons as something other than suite delimiters - it 
breaks up the affected expression too much (particularly function calls). Code 
with dict literals inside function calls bugs me for the same reason (it's OK 
when the literal is separated out into an assignment statement for the dict).
   It's also too easy to write lambdas which look ambiguous, even though they 
technically aren't.
   Finally, Python has a reputation as "executable pseudocode". Lambda 
expressions don't read like any sort of psuedocode you're likely to see outside 
a maths department.

2. The limitation to a single expression
   I consider this no more of a problem than the restriction to a single 
expression in the main loop of a generator expression or a list comprehension. 
When those get too complicated, you switch to using a real for loop somewhere. 
Deferred expressions are no different - when the guts get too complicated, 
switch to a named function.

3. The word 'lambda' itself
   This _is_ one of my objections for the reasons stated above: for people 
unfamiliar with the term, they don't know what it is; for people familiar with 
the term, it isn't what they think it should be.
   Python already has a perfectly good keyword for functions, which has the 
additional virtue of being half the length of lambda (this matters, since this 
is a keyword that gets embedded in expressions - all the other keywords 
currently in that category are three letters or less: and, or, is, in, for)

4. People complaining about 2
   Oh hell yes, this bugs me. And I think changing the syntax and calling them 
"deferred expressions" instead of "lambdas" would go a long way towards 
eliminating the griping.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net