`(*args: Any, **kwargs: Any)` not treated as equivalent to gradual signature `...`

[randolf-scholz]

Describe the Bug

According to the typing spec

If the input signature in a function definition includes both a *args and **kwargs parameter and both are typed as Any (explicitly or implicitly because it has no annotation), a type checker should treat this as the equivalent of .... Any other parameters in the signature are unaffected and are retained as part of the signature

The example from the spec, copy-pasted into sandbox, gives 4 false positives

from typing import Any, Protocol, assert_type, Concatenate, Callable

class Proto1(Protocol):
    def __call__(self, *args: Any, **kwargs: Any) -> None: ...

class Proto2(Protocol):
    def __call__(self, a: int, /, *args, **kwargs) -> None: ...

class Proto3(Protocol):
    def __call__(self, a: int, *args: Any, **kwargs: Any) -> None: ...

class Proto4[**P](Protocol):
    def __call__(self, a: int, *args: P.args, **kwargs: P.kwargs) -> None: ...

def func(p1: Proto1, p2: Proto2, p3: Proto3) -> None:
    assert_type(p1, Callable[..., None])                    # Spec: ✅️ pyrefly: ❌️
    assert_type(p2, Callable[Concatenate[int, ...], None])  # Spec: ✅️ pyrefly: ❌️ 
    assert_type(p3, Callable[..., None])                    # Spec: ❌️ pyrefly: ❌️
    assert_type(p3, Proto4[...])                            # Spec: ✅️ pyrefly: ❌️

class A:
    def method(self, a: int, /, *args: Any, k: str, **kwargs: Any) -> None:
        pass

class B(A):
    # This override is OK because it is assignable to the parent's method.
    # Spec: ✅️ pyrefly: ❌️
    def method(self, a: float, /, b: int, *, k: str, m: str) -> None:
        pass

Sandbox Link

https://pyrefly.org/sandbox/?project=N4IgZglgNgpgziAXKOBDAdgEwEYHsAeAdAA4CeS4ATrgLYAEALqcROgOZ0Q3G6UN0BBdKQA0dAArUGuAMa4oY1HDgw%2BAfSbEYYgMK50M1Axjoj2ujtRQoqbLAA66RzJvKJU3AEYAFJNzS5KABKREc6cLpMGDA6NTVDazjvFSgwMQAqVEo2OERBYQz0gGsAdyycvKFSILoAWgA%2BOgA5fRg8wg7HZ1c4d39cACZfD0CQsIiomLiEqCSUtLpUPNYGMQB6DPK4QtKtmobm1vbOpwMevukAZmH%2B0dD0CMjo2PirWbVkmFTFZfRVuky2Vy%2BVEAOKZSBlWE%2B0aLXQbToHUIXTOSl6fmkABYANrpdLiAC6NwC8jGDwmz2mbzmXwWS04f02kIkhC2OwhFRZuyBMMO8OOyNOkzoYAArgZvMRPHkMV4xMQBjKPAN5Zclf1Lry4W1xuE0aoGBpmDBJZ5dG9bLBsUixNqCTVHo6nY8AMR0ADKWhkeUAoOSAeD%2B6GRKNEoKQ8oAZcj9usWygNRq0kpVFgtdhg2L0BjMpmM2JWYiRBNtrXt4Tdnpg3ro-sDpGDYFDEYD0f16k0JuIl3N1ktaZtfJgJedQ9dHq9jZrdYbdEjzdjreNks7F1wOILDuHG%2BdZbHVYDQZDYenUdOLjRgnuj2FNBgDAAFrhMJ9votfv8NgCtlDQUU8nAGJR2U-EEtSOaNHmINEUVPNwACFvAEMkRwAFVvCBelwAA3VRKAgKJOF6AB5ABpOhsArVBRRUTh%2BDQmM4AgNhTFTRhcEYW8YEDLITAYAByXprzvB9BRHctK2rfd60PGdyXCK8b3vR95h%2BEUoFwIx1jEbBXwyMQfzoP8ALoGhf3-ED%2BTAiIIOUEARBAUUGGgOASHIRAQDdABVByoAgJgRXFGQHP0OAUWFMBeBoIw1HQUUaDIyhvHwV9eQMi8ImDBhRUoB4wHsEAmhiuK8mAfAAF9cscGyQAk0NCGkGgoAoN1xFrA99IwHACDoOR0EgNhMqMCB9EFMsYA428GAYYhcjWNZqtIQheDYNYTDWTBZDgNZut6-rAvQNYRV4RYMNQaAey6-RtsoAb9DoXBiF2pzHDIQT0FqLDKHom6AF46Fyy5CE8AZyvQEASts1AAogLCADFoBgCg0CwPAiDIUGgA

(Only applicable for extension issues) IDE Information

No response

[yangdanny97]

Thanks for the detailed report!

[yangdanny97]

The assert_type cases are an issue with the assert_type implementation, not our subtyping rules. The equivalence holds during actual usage, as seen here: https://pyrefly.org/sandbox/?project=N4IgZglgNgpgziAXKOBDAdgEwEYHsAeAdAA4CeS4ATrgLYAEALqcROgOZ0Q3G6UN0BBdKQA0dAArUGuAMa4oY1HDgw%2BAfSbEYYgMK50M1Axjoj2ujtRQoqbLAA66RzJvKJU3AEYAFJNzS5KABKREc6cLpMGDA6NTVDazjvFSgwMQAqVEo2OERBYQz0gGsAdyycvKFSILoAWgA%2BOgA5fRg8wg7HZ1c4d39cACZfD0CQsIiomLiEqCSUtLpUPNYGMQB6DPK4QtKtmobm1vbOpwMevukAZmH%2B0dD0CMjo2PirWbVkmFTFZfRVuky2Vy%2BVEAOKZSBlWE%2B0aLXQbToHUIXTOSl6fmkABYANrpdLiAC6NwC8jGDwmz2mbzmXwWS04f02kIkhC2OwhFRZuyBMMO8OOyNOkzoYAArgZvMRPHkMV4xMQBjKPAN5Zclf1Lry4W1xuF8NKLG9bLBsUixNqCXQALx0KWPe0OiK6uj4RWG6zGmDYvQGMymYzYlZiJEE82tS02hXO-Bq902Oxes18mAR22XaOY9VY00dVPEdPk8J2m3650K60ugZly4VmMoxwgEQgMiUaJQUiEaQ0KAUADEElIrbA7boaCweHwdDk6EgbFFlCMEH0gv7AGUYDA6AALBgMYi5NZrFttju8NhrExrTCyOBraez%2BeL-RrEW8RYAN1Q0E9U-0D4XDBLg8uDEIB%2BhwIKZAMFu%2Bi1O%2BqhwEBFb2CAlyEJ4VYgA2AC%2BTaoDIgHwQAYtAMAUGOOAECQ5DYUAA

Our assert_type implementation simplifies the types and checks if they're exactly equal. In this case, we do not simplify callable protocols to be equivalent to callable types.

The documentation around the expected behavior is ambiguous: https://typing.python.org/en/latest/spec/directives.html#assert-type

There's this

Type checkers should aim to minimize cases where they reject assert_type() calls that use equivalent types.

but also

If the two types are equivalent but syntactically different, the type checker may reject the assert_type() call

Based on the latter point I'd argue our existing behavior is not a bug per the spec, but making assert_type treat them as equal would not be a bug either.

[randolf-scholz]

Nice find! Though, what about the override error in B(A)? This is the one that actually prompted me to open this issue.

[yangdanny97]

That one is probably a bug, I'm still looking into it

[yangdanny97]

Interesting, I guess based on the spec, any sort of override is allowed if either signature has *args: Any, **kwargs: Any, regardless of what other parameters are present. Pyright accepts these two odd examples as well:

https://pyright-play.net/?strict=true&code=GYJw9gtgBALgngBwJYDsDmUkQWEMpgBuApiCEgCbEA0UAginAFBMDGANgIYDO3UAQj2IAuJlHFQqwKBGIwAFmAoBGABTdi7YLU7DMKGLQD0tAFScQabnoZxaAaz2pDUU6fsB3C1ZuMAlFAAtAB8UAByYCgiUAB0cSwcPHwAIqRIJBSqghp%2BohJQAAJEpORUYhJSMnKKKuqawAEh4ZHRcTEJXLwCQgBMeRXE0rIKSmoaWo2hEVF6bR1JUKnkGT1Zvbnl4kUkZJTEm5KDVSO149pQuvouJq7e1vSMDk4GZu5elve2k80zsXFAA

[randolf-scholz]

@yangdanny97 Yes, having both *args: Any and **kwargs: Any basically means the signature is partially unknown. It allows for more precise partially known signatures that just combining Concatenate with ...

for instance:

• Callable[Concatenate[int, ...], Any] covers any callable that:

  1. accepts at least one positional argument
  2. the first positional argument can be an integer

  So (x: int, /) -> None, def (x: int) -> None, (x: int, *, kw: str) -> None are all valid, but (a: str, x: int) -> None is not

• a Callback-Protocol with def __call__(self, x: int, *args: Any, **kwargs: int) -> Any covers any callable that

  1. accepts at least one keyword-or-positional argument "x"
  2. the type of x can be int.

  So this wouldn't be compatible with (x: int, /) -> None but with def (x: int) -> None and (a: str, x: int) -> None

• a Callback-Protocol with def __call__(self, *args: Any, x: int, **kwargs: int) -> Any covers any callable that

  1. accepts at least one keyword-only argument "x"
  2. the type of x can be int.

Here's a larger demo, though I noticed that there seems to be some disagreement in the Keyword-only case between mypy, pyright and what I interpret the spec to say. Code sample in pyright playground mypy-playground

from typing import Callable, Concatenate, Protocol, Any

# subtypes must accept at least 1 positional argument
# the first posiitonal argument can be an `int`
type AcceptsPositionalX = Callable[Concatenate[int, ...], Any]

class AcceptsPositionalOnlyX(Protocol):
    # subtypes must accept `x` as positional argument
    # x must be the first positional parameter
    def __call__(self, x: int, /, *args: Any, **kwargs: Any) -> Any: ...

class AcceptsPositionalOrKeywordX(Protocol):
    # subtypes must accept `x` as positional argument
    # subtypes must accept `x` as keyword argument
    # x must be the first positional argument
    def __call__(self, x: int, *args: Any, **kwargs: Any) -> Any: ...

class AcceptsKeywordOnlyX(Protocol):
    # subtypes must accept `x` as keyword argument
    def __call__(self, *args: Any, x: int, **kwargs: Any) -> Any: ...

# with a prefixed positional argument
def prefixed_po(a: str, x: int, /) -> None: ...
def prefixed_pk(a: str, /, x: int) -> None: ...
def prefixed_ko(a: str, /, *, x: int) -> None: ...
# with a postfixed keyword argument
def postfixed_po(x: int, /, *, kw: str) -> None: ...
def postfixed_pk(x: int, *, kw: str) -> None: ...
def postfixed_ko(*, x: int, kw: str) -> None: ...

_p0: AcceptsPositionalX = prefixed_po # ERR (x does not come first!)
_p1: AcceptsPositionalX = prefixed_pk # ERR (x does not come first!)
_p2: AcceptsPositionalX = prefixed_ko # ERR (x does not come first!)
_p3: AcceptsPositionalX = postfixed_po # OK
_p4: AcceptsPositionalX = postfixed_pk # OK
_p5: AcceptsPositionalX = postfixed_ko # ERR (cant pass x positionally)

_po0: AcceptsPositionalOnlyX = prefixed_po  # ERR (x does not come first!)
_po1: AcceptsPositionalOnlyX = prefixed_pk  # ERR (x does not come first!)
_po2: AcceptsPositionalOnlyX = prefixed_ko  # ERR (x does not come first!)
_po3: AcceptsPositionalOnlyX = postfixed_po # OK
_po4: AcceptsPositionalOnlyX = postfixed_pk # OK
_po5: AcceptsPositionalOnlyX = postfixed_ko # ERR (cant pass x positionally)

_pk0: AcceptsPositionalOrKeywordX = prefixed_po  # ERR (cant pass x as keyword)
_pk1: AcceptsPositionalOrKeywordX = prefixed_pk  # ERR (x does not come first!)
_pk2: AcceptsPositionalOrKeywordX = prefixed_ko  # ERR (cant pass x positionally)
_pk3: AcceptsPositionalOrKeywordX = postfixed_po # ERR (cant pass x as keyword)
_pk4: AcceptsPositionalOrKeywordX = postfixed_pk # OK
_pk5: AcceptsPositionalOrKeywordX = postfixed_ko # ERR (cant pass x positionally)

_ko0: AcceptsKeywordOnlyX = prefixed_po  # ERR (cant pass x as keyword)
_ko1: AcceptsKeywordOnlyX = prefixed_pk  # ??? (should be OK, but pyright ERR)
_ko2: AcceptsKeywordOnlyX = prefixed_ko  # OK
_ko3: AcceptsKeywordOnlyX = postfixed_po # ERR (cant pass x as keyword)
_ko4: AcceptsKeywordOnlyX = postfixed_pk # ??? (should be OK, but pyright ERR)
_ko5: AcceptsKeywordOnlyX = postfixed_ko # OK

[randolf-scholz]

I think the discrepancy in the keyword-only case has to do with pyright not allowing to override a KW-Only parameter with a positional or keyword:

class Foo:
    def demo(self, *, x: int) -> None: ...

class Bar(Foo):
    # OK: [mypy, ty, zuban, pyrefly] ERROR: [pyright]
    def demo(self, x: int) -> None: ...

[github-actions]

This issue has someone assigned, but has not had recent activity for more than 2 weeks.

If you are still working on this issue, please add a comment so everyone knows. Otherwise, please unassign yourself and allow someone else to take over.

Thank you for your contributions!

[yangdanny97]

When I was working on a fix, I saw a case in the conformance tests that do not handle *args: Any + **kwargs: Any gradually.

Mypy accepts this but pyright does not.

Reduced snippet below:

from typing import (
    Any,
    Protocol,
    TypeVar,
)

T_contra = TypeVar("T_contra", contravariant=True)

class Proto5(Protocol[T_contra]):
    def __call__(self, *args: T_contra, **kwargs: T_contra) -> None: ...

class Proto8(Protocol):
    def __call__(self) -> None: ...

def func5(
    p8: Proto8
):
    err1: Proto5[Any] = p8  # E