On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 11 Feb 2021 12:24:55 +0100
> "J. Pic" <jpic@yourlabs.org> wrote:
>
> > Hi all,
> >
> > Lambdas can be defined as such:
> >
> > w = lambda: [12]
> > x = lambda y: len(y)
> >
> > I'd like to propose the following:
> >
> > w = (): [12]
>
> What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> of empty tuple mapping to a list, where do you see lambda here?
This could be solved with parentheses, but I think it'd probably be better to use similar syntax to C#, Java, and Javascript instead, and use () -> [12] or () => 12...
Agreed. I'd prefer the JavaScript solution, since -> already has a different meaning in Python return *type*. We could use -> to simplify typing.Callable, and => to simplify lambda.
It's worth noting that all three of these are later additions to their respective languages, and they all have earlier, more difficult, ways of writing nested functions within expressions. Their designers saw the benefit of an easy lambda syntax, why don't we?
Probably we were blinded by the endless search for for multi-line lambdas. It's not too late.
It also may be worth looking at what it would take to allow asynchronous lambdas. Syntactically, while "any lambda containing await" is tempting, the lack of static typing means that we need a way to specify async lambdas that do not contain await. Javascript prefixes the argument list with async [i.e. "async () => ..." or "async onearg => ..."], as does C# even though it could in principle get away without doing so because of static typing.