Be bold, they say...
On Mon, Feb 15, 2021 at 02:13:38AM +1100, Steven D'Aprano wrote:
> If I'm wrong, I'm sure somebody will point that out. I'm not frightened
> of making bold claims that turn out to be wrong: that just means I have
> learned something new. (Or something old that I forgot.)
Okay, there is an ambiguity, if arrow function syntax includes
annotations with the syntax I suggested. I had:
(values:List[float], arg:int=0 -> Type) -> expression
Using that syntax, there is an ambiguous case:
(arg=(a, b) -> T) -> expression
That could mean:
* Default value of arg is the arrow function `(a, b) -> T`;
* Or the default value of arg is the tuple `(a, b)`, and the arrow
function has the return type T.
This may suggest that, like lambda, we should just not allow annotations
in arrow functions; or that we need a better way to include the return
annotation.
The third fix is to use `=>` for the arrow functions, but this has many
down-sides, as previously discussed.
Anyway, the rest of my claim still stands (I think): if arrow functions
don't include annotations there is no ambiguity between function
annotations and arrow functions.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/FFXEX54RWDCWEZ2D2DENQEZCZ2WYVGWJ/
Code of Conduct: http://python.org/psf/codeofconduct/
