As it stands, Guido van Rossum has suggested that lambda forms will disappear in Python3.0. This started a number of threads on comp.lang.python suggesting alternate syntaxes for lambda in the hopes that one of them might be more amenable to GvR's tastes. This pages summarizes these suggestions.
- Update: GvR has changed his tune; lambda will remain unchanged.
(Reference: http://mail.python.org/pipermail/python-dev/2006-February/060415.html). This page is kept as a historic record only -- none of the proposals below satisfied GvR's taste.
The main hope of this page is to find a way to retain the functionality of existing Python lambdas - a way to create simple deferred expressions within another expression. For many uses (e.g. lazy argument evaluation, or simple callbacks) separating the deferred expression out into a named function can actually reduce clarity, as it overemphasises the deferred expression at the expense of the expression that the deferred expression is only one part of.
Goals for Alternate Form
Definitely Desirable Features
- Acceptable to BDFL
- If Guido doesn't like it, it ain't gonna happen!
- At least as capable as current lambda expressions
- If a new syntax is to replace the status quo, it needs to be at least equivalent in expressiveness
- More Pythonic / Less ugly
- The current lambda syntax simply doesn't blend well with the rest of Python's syntax. A syntax which mixes in with other expressions as cleanly as list comprehensions and generator expressions do should have a much better chance of gaining BDFL approval.
- More friendly to inexperienced users
- Compared to other Python keywords, 'lambda' is rather esoteric. In the challenge for "farthest outside day-to-day English usage", its closest competitor would probably be 'assert', as even 'def' and 'elif' are just abbreviations for 'define' and 'else if'. Use of simpler keywords may make deferred expressions appear less intimidating than they seem with the current unusual keyword.
- Less external baggage
- One of the problems with lambda is that developers familiar with lambda calculus expect more of it than it provides. They expect full anonymous functions, whereas Python's lambda expressions allow deferred evaluation of only a single expression. An alternate syntax described as providing deferred evaluation of expressions rather than anonymous functions may be less prone to trigger complaints about the single expression limitation (consider: how often are complaints heard regarding the restriction of the expression section of list comprehensions or generator expressions to single expressions?).
Arguably Desirable Features
- Support anonymous suites
- No discussion of lambda is complete without it being suggested that it should be possible to embed entire suites inside expressions. Accordingly, some suggestions along these lines are included below under the heading Real Closures.
Args Before Expression
Nick Coghlan: def-to syntax 1]
Nick Coghlan: def-arrow syntax 1]
Alex Martelli: def-as syntax 2]
Dave Benjamin: fun syntax 7]
Roman Suzi: quote-colon syntax 9]
Ka-Ping Yee: arrow syntax
Tom Anderson: anonymous def syntax, normal form 12]
Tom Anderson: anonymous def syntax, shorthand form 12]
Anders Munch: bare def syntax
Expression Before Args
Nick Coghlan: post-def syntax This is based on the "normally nested expression before statement keyword" idiom used with generator expressions, list comprehensions and PEP 308 conditional expressions.
Nick Coghlan: for syntax 6]
Robert Brewer: for (no-parens) syntax 3]
Nick Coghlan: def-from syntax 4]
Nick Coghlan: from syntax (posted to clp, no reference handy)
Michael Spencer: from-args syntax 5]
Michael Spencer: for-args syntax 5]
Bengt Richter: colon-function-application syntax 8]
Talin: 'given' keyword (Same as the 'for no parens' except uses a different keyword.)
lwickjr: How about converting the lambda functionality into a function? For example, in pure can-do-now Python:
1 from types import FunctionType as function 2 def anonymous( 3 name=None, 4 filename=None, 5 mode="eval", 6 func_globals=None, 7 func_closure=None, 8 func_argdefs=(), 9 flags=0, 10 dont_inherit=False, 11 source=None, 12 code=None, 13 ): 14 """Create a possibly anonymous function inline""" 15 ## Compute suitable default values from stack frame, omitted for brevity. 16 if source: code = compile(soource, filename, mode, flags, dont_inherit=True) 17 return function(code, func_globals, name, func_argdefs, func_closure)
If you don't like anynomous for the name, suggest something else!
Real closures subsume the functionality of lambda plus allow for multi-line statements.
Curly braces for single-line and anonymous def for multi-line (from 10], boo 11], and this is also very similar to how Ruby does it):
Perhaps anonymous def for single line, anonymous def for single-line?
foo.addCallback(def (result): result + 1) foo.addCallback(def (result, myExtra, args): print 'hi!' result += 1 return result , extra, args=here)
Tom Anderson's syntax (which is subtly different - it still wants a return in single-line anonymous defs) could also be used for multi-line closures in this way.