Is Type Propagation for Overloaded Functions Well-Supported?

[ckwastra]

The following code is accepted by mypy, but not by Pyright:

from typing import overload

@overload
def f() -> None: ...
@overload
def f(_: bool) -> None: ...

def f(_=False): ...

class C:
    f = f

f()
C.f()

f(True)
C.f(True)  # Pyright: Expected 0 positional arguments

I'm unsure whether such usage is recommended. Should we define a separate type for C.f here (perhaps using typing.Protocol)?

[erictraut]

The problem here is that you're defining an instance method that doesn't accept a self parameter.

You can see the problem more clearly if you do this:

Code sample in pyright playground

class A:
    def x() -> None: ...
    def y(_: bool) -> None: ...

A.x
A.y

To fix your code, here are some suggestions.

1. You can mark the function as a staticmethod:

@overload
@staticmethod
def f() -> None: ...
@overload
@staticmethod
def f(_: bool) -> None: ...

@staticmethod
def f(_=False): ...

Unfortunately, mypy doesn't like this approach.

2. Define a new static method:

class C:
    @overload
    @staticmethod
    def f() -> None: ...
    @overload
    @staticmethod
    def f(x: bool, /) -> None: ...
    @staticmethod
    def f(x: bool = False, /):
        return f(x)

This admittedly involves duplicating some boilerplate, but it is compatible with mypy.

---

Pyright's error message for your original code snippet isn't very clear, so I've updated the logic to improve the error message. This will be included in the next release.

[ckwastra]

Thanks for the insight into staticmethod. I'm also wondering whether the following code (using Protocol) could do the trick:

from typing import Protocol, cast, overload, reveal_type

@overload
def f() -> None: ...
@overload
def f(x: bool, /) -> None: ...

def f(x: bool = False, /) -> None:
    print(x)

class C:
    class F(Protocol):
        @overload
        def __call__(self, /) -> None: ...
        @overload
        def __call__(self, x: bool, /) -> None: ...
        def __call__(self, x: bool = False, /) -> None: ...

    f: F = staticmethod(f)  # mypy, Pyright: Incompatible type
    g = cast(F, staticmethod(f))

reveal_type(f)
reveal_type(C.f)
reveal_type(C.g)

f()
C.f()
C.g()

f(True)
C.f(True)
C.g(True)

Are we required to use cast in this case (like with C.g above)?

[erictraut]

staticmethod requires special-casing in a type checker, and this special-casing is applied only when it is used as a decorator. When you use it in other contexts, it is treated like any other class, and the special-case logic is not applied. This means that the expression staticmethod(f) evaluates to a value of type staticmethod, which is not assignable to F.

You could use a cast here, but I personally avoid using cast calls because they make the code more fragile. Since you're lying to the type checker, it could mask errors that are introduced during future code changes. But if you're comfortable using cast here, that would work.