Just to be clear, by "function prototype", do you mean what PEP 677 calls a Callable Type? A "function prototype" would be a concrete type that exists alongside the function type. The objects would hold the arguments, defaults, annotations and name of a function.
What sort of implications beyond typing? Here are a few places where "function prototypes" would be useful:
import ctypes @ctypes.CFUNCTYPE def f(a: ctypes.c_int) -> ctypes.c_int import abc class Model(abc.ABC): def get_id(self) -> int By returning a concrete object, I leave it up to the implementation to define its meaning.
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"? Yes, it would create a "function prototype" object.
What does it need the @Callable decorator for? The @Callable decorator is not needed, it's just something leftover from Mark Shannon's proposal. Interpretation is entirely up to type checkers.
What happens if you leave out the annotations and just say `def Func(a)` alone? The same thing that happens when you create a function with no annotations.
Do you have any response to my other criticisms about this syntax? Maybe I'm misinterpreting your reply, but I don't see any other criticisms about the syntax besides the one I addressed. The rest seem to be geared towards Mark Shannon's proposal.
What does that mean? What is lazy about it? I called it lazy because it fixes the callable syntax with little to no care about how it affects the future (if any) of the lambda syntax. I firmly believe that fixing the callable syntax and revising the lambda syntax should be done at the same time, or at least done in a way that doesn't make a new lambda syntax impractical.
Creating new syntax is backwards compatible: it doesn't break existing code that is syntactically correct. I meant this in the context of my proposal where the lambda syntax and "callable" syntax are tightly coupled. Apologies if that wasn't clear.