My eyes are bleeding with these incomplete function definitions. If you are using decorators and "def", then, please, there is no need for special syntax that would just be a syntax error in "normal"Python., Just add ": pass" to the end.
If eyes bleeding is not enough of an argument for you: the new syntax would only be possible be usable in code that would run on Python 3.11 and above. While using the decorator + function declaration syntax, you have the annotations that could readly be checked and code compatible with existing all supported Python versions, right out of the box. On 2021年12月23日 at 16:31, MRAB <[email protected]> wrote: > On 2021年12月23日 19:04, [email protected] 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/AKS4IHJJFDV24QZNMVMFZR72H5ORU3TB/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/BGQUJQCBW72WDGRKXT5JXKS2AEBS36OJ/ Code of Conduct: http://python.org/psf/codeofconduct/