Protocol seems to only match the first overload

[twoertwein]

I want to type the operators of a class that forwards all the operators to the operators of a wrapped type. It seems that I can (ab)use protocols for that purpose, see the example below - but it fails to work when a class uses overloads where the relevant overload isn't the first one.

# pyright: reportInvalidStubStatement = false
from __future__ import annotations
from typing import Protocol, TypeVar, overload, Generic

_T = TypeVar("_T", covariant=True)
_Other = TypeVar("_Other", contravariant=True)
_Result = TypeVar("_Result", covariant=True)

# let's ignored __radd__ to keep it simpler
class add(Protocol[_Other, _Result]):
    def __add__(self, other: _Other, /) -> _Result: ...

# some class acting as a container that forwards operators to the underlying type
class Series(Generic[_T]):
    def __add__(
        self: Series[add[_Other, _Result]], other: _Other, /
    ) -> Series[_Result]: ...

class Timedelta:
    @overload
    def __add__(self, other: Timestamp, /) -> Timestamp: ...  # relevant overload
    @overload
    def __add__(self, other: int, /) -> Timedelta: ...

class Timestamp:
    @overload
    def __add__(self, other: int, /) -> Timestamp: ...
    @overload
    def __add__(self, other: Timedelta, /) -> Timestamp: ...  # relevant overload

def test_timedelta_timestamp(x: Series[Timedelta], y: Timestamp):
    # works (relevant overload of Timedelta.__add__ is the first one)
    reveal_type(x + y)

def test_timestamp_timedelta(x: Series[Timestamp], y: Timedelta):
    # fails (relevant overload of Timestamp.__add__ is not the first)
    reveal_type(x + y)

xref pandas-dev/pandas-stubs#820

[erictraut]

I agree this is an abuse of the type system, and I don't recommend you use this approach. You're in very iffy and indeterminate areas of the type system.

The constraint solver, when solving for the TypeVar _Other in the add protocol must arbitrarily choose from either the first or second overload since both of them match the add.__add__ method. Choosing the first one seems like a logical choice, since that mirrors the general overload matching behavior for calls.

[twoertwein]

Thank you, I hoped that the TypeVar+Protocol approach might act like a "solver" (pick the matching overload if available and then bind to it). I got that idea from typeshed's iter, but in their case, the function has no arguments and can therefore not have overloads.

[twoertwein]

Is there currently a way to precisely type operators of classes that forward them to underlying types (or is there an existing discussion)?

Even if the above Protocol+TypeVar approach worked with overloads, it might not be ideal as 1) I think classes would need to use a covariant TypeVar for _T and 2) It probably would make type checking quite a bit slower, especially if many frequently used classes forward their annotations to other types.