
Is this also why re-using an actual callable at a type was rejected?
The idea to use a function as a type (which Łukasz proposed at the PyCon typing summit) is still under consideration. Our thought was that it would probably be a separate PEP from a syntax change. Personally, I think we should both adopt function-as-a-type and shorthand syntax, and reject both the XOR and hybrid syntax because function-as-a-type is convenient for expressing the same things (named, default-value, and variadic args). We don't think function-as-a-type solves all cases for a few reasons: (1) in existing code, Pradeep's data analysis shows that the use of named arguments in calls is quite rare, less than 5% of cases; positional arguments are at least 12 times more common. As a result, we think it's important to have an option where positional arguments are convenient. We don't think the `/` or underscore conventions would be very convenient; `/` in particular would be easy to forget, which would lead to accidentally pinning argument names. It's easy to imagine library authors not realizing they did this, particularly their unit tests use the same argument names. (2) Callable is one of the most heavily used types. So we do think the ability to inline it may be important. (3) Around 20% of Callables in existing code Pradeep analyzed require a ParamSpec. That's 4 times the number of callables that made use of default arguments or named arguments. It is not easy to make use of ParamSpec in function-as-a-type, but it is easy to support with a new shorthand syntax.