@overload with multiple Generic[Any]

[randolf-scholz]

Am I missing something, or is it impossible to annotate op in a way that satisfies the assert_type test-suite in the example below?

from typing import Any, overload, assert_type

class A[T]:  # covariant
    def get(self) -> T: ...

@overload
def op(l: A[None], r: A[None]) -> A[None]: ...
@overload
def op(l: A[None], r: A[Any]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[None]) -> A[None]: ...
@overload
def op(l: A[Any], r: A[Any]) -> A[Any]: ...
def op(l, r):
    # dummy implementation:
    if l.get() is None or r.get() is None:
        return A[None]()
    return A[Any]()

def test(x: A[None], y: A[Any]) -> None:
    assert_type(op(x, x), A[None])
    assert_type(op(x, y), A[None])  # ❌️: (mypy, zuban)
    assert_type(op(y, x), A[None])  # ❌️: (mypy, zuban)
    assert_type(op(y, y), A[Any])   # ❌️: (pyright, ty, pyrefly)

The schema is relevant for type hinting numeric types that interact with math.nan / nullable values.

[randolf-scholz]

The alternative of not preserving None in the mixed case makes mypy and zuban happy, but gives even worse results on the other type checkers:

from typing import Any, overload, assert_type

class A[T]:  # covariant
    def get(self) -> T: ...

@overload
def op(l: A[None], r: A[None]) -> A[None]: ...
@overload
def op(l: A[None], r: A[Any]) -> A[Any]: ...
@overload
def op(l: A[Any], r: A[None]) -> A[Any]: ...
@overload
def op(l: A[Any], r: A[Any]) -> A[Any]: ...
def op(l, r):
    # dummy implementation:
    if l.get() is None or r.get() is None:
        return A[None]()
    return A[Any]()

def test(x: A[None], y: A[Any]) -> None:
    assert_type(op(x, x), A[None])
    assert_type(op(x, y), A[Any])  # ❌️: (pyright, pyrefly, ty)
    assert_type(op(y, x), A[Any])  # ❌️: (pyright, pyrefly, ty)
    assert_type(op(y, y), A[Any])  # ❌️: (pyright, pyrefly, ty)

[antoninche]

The short answer is that Python’s current static typing system does not support inferring a generic return type from an “indirect factory” method unless that type variable is explicitly connected to the function signature. This limitation arises because Python’s type checkers (e.g., mypy or pyright) need a clear relationship between the type parameter and either a function argument or a class parameter to correctly infer return types.

Why this limitation exists

• In Python typing, a TypeVar like T becomes meaningful for static analysis only when it’s tied to something the type checker can track.

• A function signature like:

  def factory() -> T:
      ...