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