`--extra-checks` is too strict when using `Concatenate` within a `Protocol`

[Daverball]

Bug Report

This is admittedly a fairly niche use-case, but this came up when adding more precise type hints to itsdangerous and trying to write a Protocol that accepts any object that has a loads and dumps method where dumps can take arbitrary extra keyword arguments.

The docs for --extra-checks state that uses of Concatenate will force positional-only for equality, but this seems incorrect to me in the specific case of a property on a Protocol, since we're performing a structural match against methods there. *args: Any, **kwargs: Any doesn't really work, because it will only be recognized as a gradual extension of the method by some type checkers and not consistently, it's also not part of the typing spec, unless I'm mistaken. So Concatenate with ... is the only way to spell this.

To Reproduce
mypy Playground

import typing as t
import typing_extensions as te

class _PDataSerializer(t.Protocol[t.AnyStr]):
    def loads(self, payload: t.AnyStr, /) -> t.Any: ...
    @property
    def dumps(self) -> t.Callable[te.Concatenate[t.Any, ...], t.AnyStr]: ...
    
class MySerializer:
    def loads(self, payload: bytes) -> t.Any: ...
    def dumps(self, obj: object, *, some_required_option: bool) -> bytes:
        return NotImplemented
    
foo: _PDataSerializer[bytes] = MySerializer()

Expected Behavior

I would expect MySerializer to match the Protocol in my example. As soon as I change the payload argument to positional-only it does. It also does if I disable --extra-checks.

Actual Behavior

It is rejected based on the first argument not being positional-only.

Your Environment

• Mypy version used: 1.9.0
• Mypy command-line flags: --strict
• Mypy configuration options from mypy.ini (and other config files):
• Python version used: 3.8-3.12

[erictraut]

This relates to a part of the typing spec that is currently unspecified but that I hope to clarify soon. The question is whether self and cls parameters should be considered position-only. When discussing this in the typing forum, the community consensus (including input from Guido) seems to be that self and cls should always be considered position-only even if they're not explicitly marked as such, and it should be considered an error to use a keyword argument to target these parameters. The next step is to formalize this decision and propose an update to the typing spec with wording that codifies this behavior.