Lambda going out of fashion

[Nick Coghlan]

Alan Gauld wrote:
> It can't be that hard to maintain the lambda code, why not just
> leave it there for the minority of us who like the concept?

Because one of the points of Py3K is to clean up the language concepts and 
syntax, and the current lambda just doesn't fit cleanly. If it was proposed in a 
PEP, the syntax would be rejected as not being sufficiently Pythonic and for 
being a castrated near-synonym for the def statement.

Now, Python 3K will retain the statement/expression distinction, so anonymous 
functions will indeed be impossible without lambda - the link from a statement 
to an expression will need to be made through the local namespace.

So, rather than pushing to retain lambda for Py3K, it might be more productive 
to find a better statement -> expression translation for function definitions. 
Guido seems to prefer named functions, so it would still be tough to gain his 
acceptance. However, a more Pythonic syntax is the only way I can see anonymous 
functions making into 3.0

The current best example of a statement->expression translation is generator 
expressions:

def squares(seq)
   for x in seq:
     yield x * x

total = sum(squares(seq))

versus:

total = sum(x * x for x in seq)

If we consider a function definition (omitting decorators and docstrings) we get:

def foo(a, b, c):
   return f(a) + o(b) - o(c)

accepts_func(foo)

What would a Pythonic 'function as expression' look like?

Perhaps something like:

accepts_func( (def (a, b, c) to f(a) + o(b) - o(c)) )

Here we simply omit the function name and use 'to' instead of ':' (the colon is 
omitted to avoid making our expression look like it might be a statement). We 
also don't need a return statement, since our target is an expression. The 
surrounding parentheses would be required.

The "def (arg-tuple) to (result)" form is intended to show that we're talking 
about a function in the mathematical sense of a single expression, rather than 
the general Python sense of a suite of statements. That is, it has the same 
behaviour as the current lambda - if you want a real Python function, write a 
real Python function :)

Personally, I don't see the restriction of anonymous functions to single 
expressions any more of a wart than the restriction of the value portion of a 
generator expression to a single expression. If an algorithm is too complex for 
a single expression, it's probably worth giving a name.

Some more examples:

(def (x) to x * x)    # Map values to their squares
(def () to x)         # No arguments, always map to x
(def (*a, **k) to x.bar(*a, **k)) # Look up the method now, call it later

And in combination with a generator expression:

( (def () to x(*a, **k)) for x, a, k in funcs_and_args_list)

Replacing the 'to' with -> might actually read better:

(def (a, b, c) -> f(a) + o(b) - o(c))
(def (x) -> x * x)
(def () -> x)
(def (*a, **k) -> x.bar(*a, **k))
( (def () -> x(*a, **k)) for x, a, k in func_list)

Anyway, thats just some ideas if you're concerned about the plan to have lambda 
disappear in 3K.

Cheers,
Nick.

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