On Thu, Dec 23, 2021 at 07:04:17PM -0000, asleep.cult@gmail.com wrote:
One thing that you must consider is that function prototypes
Just to be clear, by "function prototype", do you mean what PEP 677 calls a Callable Type?
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.
What sort of implications beyond typing? Some questions: 1. What kind of object does `def Func(a:int)->int` create, if you leave out the decorator? Is that what you are calling a "function prototype object"? 2. What does it need the @Callable decorator for? 3. What can you do with it, apart from typing? 4. What happens if you leave out the annotations and just say `def Func(a)` alone? 5. Do you have any response to my other criticisms about this syntax?
After reading through your reply, I am seeing that the main concern is the bloat added by the lambda keyword.
Perhaps you should re-read my reply. The lambda keyword is the *least* part of my dislike of this proposal.
The fact that lambda is hard to type has been felt by almost everyone who has ever used Python,
Such exaggerations don't help your case. I have never felt the need to type a lambda expression, and doubt I'm so very unusual. Annotations have only existed for less than half of Python's existence. Even today, I doubt that as many as half of Python's user base are heavy users of typing. Or even casual users of typing. And many of them would not use lambda, or at least not in places where adding typing to it would add any value. In any case, allowing type-hints in lambda expressions is independent of the question of using the lambda keyword to declare a function prototype. I have no objection in principle to allowing annotations in lambda expressions if such a thing would actually be useful. But that doesn't mean I want to see lambda used as function prototype syntax: def map(func: lambda (obj: Any) -> Any, items: Sequence[Any]) -> Sequence[Any] especially not in preference to just using arrow syntax: def map(func: (Any)-> Any, items: Sequence[Any]) -> Sequence[Any]
this isn't just a problem that would be introduced by function prototypes. PEP 677 has taken the lazy approach to solving this issue
What does that mean? What is lazy about it?
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.
Syntactic sugar for lambda is not part of PEP 667, it merely references the fact that people have suggested using => as shorthand for a lambda. For what its worth, I was skeptical about using two different arrows (one for declaring callable types, one for functions) when I first heard the idea (I think it was Guido who mentioned it?). But I've come to believe that whatever confusion there might be in using two arrows "do I use -> or => here? I never remember which is which" will be less, not more, than the confusion due to using the same arrow for both contexts. That is, I think, the experience from other languages. (Kotlin if I remember correctly? Maybe not.) But that's a discussion for when somebody writes a PEP for lambda shortcut syntax.
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?
Creating new syntax is backwards compatible: it doesn't break existing code that is syntactically correct. Only removing, or changing the meaning of, existing syntax will break "every Python program in existence". I doubt the Steering Council would accept such breakage. -- Steve