On 2021-12-23 19:04, asleep.c...@gmail.com wrote:
Hello and thank you for the much needed feedback.
One thing that you must consider is that function prototypes
have a few implications beyond typing but it seems like you're
only looking at it as a tool for type hinting. The interpreter will
create a function prototype object regardless of if you forget your
decorator, it needs to pass something to the decorator after all.
After reading through your reply, I am seeing that the main concern
is the bloat added by the lambda keyword. My decision to use lambda
instead of introducing a special syntax was one that required heavy
deliberation. I ultimately decided to stick with lambda because it was
consistent with the prototype statement form. The fact that lambda
is hard to type has been felt by almost everyone who has ever used
Python, this isn't just a problem that would be introduced by
function prototypes. PEP 677 has taken the lazy approach to solving
this issue and has prioritized type hinting over functionality. PEP 667
also suggests the usage of => for lambdas which would likely
never be accepted because of the confusion it would cause.
As someone who has used typing with Python, I do think that a new
callable syntax is needed, but I truly believe that PEP 677 is taking the
wrong approach.
So what if we broke every Python program in existence by creating a
new lambda syntax, how would it look? This question is particularly
hard to answer because the body and annotations both need to be
optional. Our best bet is an augmented form of the PEP 677 syntax
that allows you to add a body. Here is an example:
(a: int) -> int: a ** 2
But of course this causes ambiguity when the return annotation and
body are both omitted. One thing that I did consider is simply treating
it like a tuple if there is no return annotation AND there is no body, but
that might lead to confusion. Another thing that I considered is a different
prefix than lambda:
$(a: int) -> int: a ** 2
Usually the suggestion is to use 'def':
def (a: int) -> int: a ** 2
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/AKS4IHJJFDV24QZNMVMFZR72H5ORU3TB/
Code of Conduct: http://python.org/psf/codeofconduct/
