Custom protocols for builtin numbers

[v--]

Summary

For working with abstract algebraic structures, I found it useful to define the following protocol (with some simplification):

from typing import Protocol, Self


class ISemiring(Protocol):
    def __add__(self, other: Self, /) -> Self:
        ...

    def __mul__(self, other: Self, /) -> Self:
        ...

Consider the following simple function:

def frobnicate(x: ISemiring) -> None:
    ...


def wrapper_int(x: int) -> None:
    frobnicate(x)  # ty agrees that `int` is a subtype


def wrapper_float(x: float) -> None:
    frobnicate(x)  # ty disagrees that `float` is a subtype

See this playground page. I do not have further clues about what goes wrong (except that replacing Self with float works). complex values have the same problem. Sorry if I am missing something obvious.

Both of the above functions are fine with mypy 1.19.1 and pyrefly 0.53.0 (mypy doesn't even need the trailing slashes in the argument lists in the protocol).

Version

ty 0.0.18

[MeGaGiGaGon]

I think this is happening because of the int-float-complex special case. Looking at the typeshed definition of float, it looks fine:

class float:
    def __new__(cls, x: ConvertibleToFloat = 0, /) -> Self: ...
    def __add__(self, value: float, /) -> float: ...
    def __mul__(self, value: float, /) -> float: ...

But once you apply the special case, it instead looks like this:

class float:
    def __new__(cls, x: ConvertibleToFloat = 0, /) -> Self: ...
    def __add__(self, value: int | float, /) -> int | float: ...
    def __mul__(self, value: int | float, /) -> int | float: ...

And then because int | float is not the same as just float, these fail the Selfs in the protocol. Currently ty does not yet have the diagnostic features to tell you this, but if you plug it into a type checker that does like mypy, you get the expected output https://mypy-play.net/?gist=a680b221b7f4dbb2aa19fb221342d907 .

main.py:36: error: Argument 1 to "frobnicate" has incompatible type "MySpecialFloat"; expected "ISemiring"  [arg-type]
main.py:36: note: Following member(s) of "MySpecialFloat" have conflicts:
main.py:36: note:     Expected:
main.py:36: note:         def __add__(self, MySpecialFloat, /) -> MySpecialFloat
main.py:36: note:     Got:
main.py:36: note:         def __add__(self, MySpecialFloat | int, /) -> MySpecialFloat | int
main.py:36: note:     Expected:
main.py:36: note:         def __mul__(self, MySpecialFloat, /) -> MySpecialFloat
main.py:36: note:     Got:
main.py:36: note:         def __mul__(self, MySpecialFloat | int, /) -> MySpecialFloat | int

(Same code in the ty playground https://play.ty.dev/53312f86-02e8-46f4-a9be-b1a9220bd10e )
So my guess is that they are doing something special in the protocol assignability checks to treat int | float as Self for float, though I couldn't find anything specifically on that.

[carljm]

Thanks for the report, and @MeGaGiGaGon for the debugging!

Specifically the problem is that we widen the return type of e.g. float.__add__ to float | int -- it's fine for the argument type to be wider. (See https://play.ty.dev/f2ecc6b0-08e7-4f31-81b6-88bf13dbbadf ).

We could apply a special case for methods of float that are known to definitely return float (not int), and not apply the float | int widening there.

[carljm]

Also @v-- , you may be interested in #2818, which discusses how this pattern (Self typed arguments on protocol methods) is not really sound, and we may warn on it in future.