On Sun, Nov 29, 2020 at 1:49 AM Guido van Rossum <guido@python.org> wrote:
On Sat, Nov 28, 2020 at 9:32 AM Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
I would see support of all argument kinds support in any proposal for a new callable: positional only args, named args, keyword-only, *args and **kwargs.
The exact notation in probably less important than missing functionality.

Hm, but using Protocol you can already express every callable type. We could duplicate all of the complexity of 'def' parameter lists into the type notation, but it would be very complex. So this requirement is at least debatable (I'm not actually sure how I feel about it).
Don't get me wrong please. I'm not the typing system developer (while use typing every day in my code).
You can consider this email as end-user feedback.

I have a lot of code that uses `Callable[]` annotation; it is a natural way of annotating any callable, isn't it.
Sometimes `Callable` doesn't work. For example, I cannot annotate a function that accepts a keyword-only argument.

Sure, I can use Protocol but it doesn't feel natural and requires more code lines, especially if the Protocol is used once or twice.
Also, Protocol adds `self` to methods which looks at least confusing when I annotate plain callables which naturally don't belong to any class:

class MyFunc(typing.Protocol):
    def __call__(self, /, arg: int) -> str: ...

Moreover, I recall a pull request to only of my libraries that had something similar to:

class MyProto(typing.Protocol):
    def __call__(self_, /, self: Class, arg: int) -> str: ...

The protocol actually had two 'self': one fake self for protocol itself and another one if the *real* self.
The PR was refactored to use a more *natural* style but my first reaction was eyeballs :)

The last thing that is unclear for me is mixing protocols with ParamSpec from PEP-612.

Sure, I can live with all the mentioned limitations and learn all the required tricks if we have a consensus that Callable should operate with positional unnamed arguments only; but allowing to write such things in a manner similar to that Python supports for function definitions already makes life easier.

Andrew Svetlov