[Python-ideas] Thoughts on lambda expressions

[Nick Coghlan]

On 3 March 2016 at 06:01, Abe Dillon <abedillon at gmail.com> wrote:
> More generally, I think a superior syntax for lambda would be:
>
> (<expression> from <signature>)
>
> The reasons I believe that's a superior syntax are:
>
> a) In the vast majority of use cases for lambda expressions the call
> signature can be easily inferred (like in a key function), so moving it
> after the expression tends to be more readable.

This observation isn't necessarily accurate, as many uses of lambdas
regularly rely on lexical scoping to look up some values (hence why
the late binding behaviour of such lookups is frequently cited as a
problem).

> b) It doesn't use the esoteric name, 'lambda' which causes its own
> readability issues.

Given the readability issues caused by overuse of lambda, there's a
school of thought that sees "I like lambda functions, but don't like
the lambda keyword, so I avoid using lambda expressions in Python" as
a desirable characteristic of the status quo.

> c) It should be compatible with existing code:
>
> try:
>     1/0
> except Exception as e:
>     raise (ValueError() from e)  # this is already a syntax error so
> implementing the proposal won't break working code
>                                  # of this form. I'm not aware of any other
> uses of the 'from' keyword that would create
>                                  # ambiguities

Right, the main downside from an "existing syntax" perspective is that
it would be a 3rd use of "from" that's semantically unrelated to the
existing uses (imports, exception chaining).

> I'm not sure if this should actually be implemented, but I wanted to share
> the idea anyway and get some feedback. In my opinion 'lambda' is one of the
> less elegant pieces of Python syntax not because it's restricted to a single
> expression, but because the name and syntax are both detrimental to
> readability.

I'm personally not averse to adding new syntactic sugar for lambda
expressions, but if we did do something like that, I'd advocate for
just stealing Java's spelling (perhaps with the addition of mandatory
parentheses, ala generator expressions):
https://docs.oracle.com/javase/tutorial/java/javaOO/lambdaexpressions.html#syntax

The rationale for that would be:

1. "(params -> expr)" is easier on the eyes than "lambda params: expr"
2. "->" is already used to separate function parameter definitions
from the return type annotation
3. It makes moving back and forth between Java & Python easier
4. Swift uses '->' to separate the parameter type and return type
declarations in closure expressions [1]
5. It's also similar to the C# lambda expression syntax (which uses
"=>" rather than "->") [2]
6. JavaScript ES6 also has an "arrow function" construct similar to
the C# lambda expression [3]

While that may sound like an "argument from popularity" (and there are
certainly aspects of that), my main rationale for advocating for
consistency with other popular (or operating system vendor backed)
languages with similar capabilities would be to *increase Python's
value as a teaching language*: making semantically similar constructs
look similar to the way they look elsewhere makes it easier for folks
that start their text-based programming education with Python to later
make the move to a different platform (if that's where their career
and interests takes them), and "helps in preparation for other
environments" is a positive characteristic in a world where developers
are spoiled for choice when it comes to programming languages and
runtimes.

However, I'm not interested enough in the idea to propose it myself -
I'm interested in the problem from an abstract language design
perspective these days, not a "this actually bothers me personally"
sense [4].

[1] https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html
[2] https://msdn.microsoft.com/en-AU/library/bb397687.aspx
[3] https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
[4] That wasn't always true, as can be seen if you search far enough
back in the dev list archives :)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia