
1. Barry Warsaw
This means that any PEP which proposes syntactic changes to support typing features must also address the implications of those syntax changes for the general Python language. PEP 646 (Variadic Generics) is a good example of this. Early on we recognized that the proposed syntax change had implications for Python, and we asked the PEP authors to address those implications for Python, which they added:
Yes, we definitely plan to include syntax implications in the PEP. (I'm co-author of PEP 646 :) ) This was one of the reasons we wanted to get high-level feedback here, since our proposal includes a syntax change for Python. 2. Łukasz As Steven mentioned, your proposal of using a function name as its type is definitely something we're keeping in mind. It comes under the "alternative proposals" I talked about in part 2. As a replacement for Callable itself (part 1), writing a separate function signature is much more verbose and inconvenient. Given how frequently we need to express simple positional-only callables (like `Callable[[Request], Response]`) and ParamSpec callables, the consensus was strongly in favor of having simple inline syntax. However, when it comes to complex features like named parameters, default values, and `**kwargs` (part 2), your proposal might well be more readable than "hybrid" syntax. These use cases rarely come up, based on our stats, so a simple, syntax-free change like yours might be better than trying to duplicate everything that can be expressed in function signatures. So, shorthand syntax + function-name-as-type could be a good overall solution for part 1 and part 2. This would give us simple and friendly syntax for the most common cases and readable syntax for the advanced cases. What do you think?