I think it's important to be aware of the subtle differences between *function
type annotations* and *callable types*. The type annotations on a function
definition (or stub) define *all* the possible ways the function can be
called. Callable types on the other hand define *one* particular way a
function can be called. When you're writing type annotations for a callback
argument, you base it on how the callback will be *called*, not how any
particular function is *defined*.
These differences also mean we have slightly different requirements from
the syntax. A function definition can have three types of arguments:
positional-or-keyword arguments (the default), positional-only arguments
and keyword-only arguments. For a callable type on the other hand there are
two types (which correspond to how the function will actually be called):
positional arguments and keyword arguments.
Due to these differences I don't think the "stub syntax" makes sense. In
order to make it unambiguous we would have to disallow
positional-or-keyword arguments, so you would always need to use / or * or
both. And even then it wouldn't be quite intuitive to newcomers that a
callable type like (a: int, /) -> bool would also match a function defined
as def foo(bar: int, baz: int = 0) -> bool. It's better to use new
intuitive syntax than to use existing syntax in unintuitive ways IMO.
The hybrid syntax makes more sense, but I would not allow * and / in this
syntax since they have no useful meaning in this context. There is also no
point being able to specify that a named argument should be optional - it
will either be given or not when calling the function, so it's irrelevant
whether the implementation provides a default value.
Variadic arguments are still needed, but giving them names would have no
meaning. Here are a few options I can think of for how they could be
specified:
- (*: int, **: Any)
- (*int, **Any)
- (*int, *: Any)
- (*int, **: Any)
I think the second option would be preferable, because it matches the
syntax for unpacking. On the other hand, the last two keep the convention
of using ":" for keyword arguments. To be clear about the meaning of this
syntax: Any matching function *has to have* corresponding *args and
**kwargs in its definition - variadic arguments in the callable type would
never match non-variadic required arguments in the function definition.
To give an example of how the hybrid syntax could be used in practice,
consider the following function taking a callback argument:
```
def foo(x: int, callback: ??) -> bool:
y = "bar"
return callback(x, y, asdf=6.5)
```
From this, writing the type annotation for the callback is straightforward:
```
callback: (int, str, asdf: float) -> bool
```
And one with variadic arguments:
```
def foo(x: Sequence[int], callback: (*int, **Any) -> bool, **kwargs: Any)
-> bool:
return callback(*x, **kwargs)
```
I'm also in favor of the proposed syntax of (...) -> T to cover the case
where it is not statically known how the function might be called, e.g. for
most decorators.
We should also consider how the new syntax will interact with PEP 612
(ParamSpec). Should the following modified example from the PEP be allowed?
```
P = ParamSpec("P")
R = TypeVar("R")
def add_logging(f: P -> R) -> (P -> Awaitable[R]):
...
```
Or perhaps even something like this?
```
def with_request(f: (Request, *P.args, **P.kwargs) -> R) -> (P -> R):
...
```
- Daniel
