__slots__ requires explicit type definition and must be Any (and nothing else) when used with Protocols

[posita]

# test_case1.py
from __future__ import annotations
from typing import Protocol, runtime_checkable

@runtime_checkable
class Foo(Protocol):
    __slots__ = ()
    def foo(self):
        ...

class Bar:
    __slots__ = ("_t",)
    def __init__(self):
        self._t = True
    def foo(self):
        pass

print(f"isinstance(Bar(), Foo) == {isinstance(Bar(), Foo)}")  # <- prints … == True
foo: Foo = Bar()  # <- errors here

% python test_case1.py
isinstance(Bar(), Foo) == True
% mypy --version
mypy 0.910
% mypy --config-file=/dev/null test_case1.py
/dev/null: No [mypy] section in config file
test_case1.py:19: error: Incompatible types in assignment (expression has type "Bar", variable has type "Foo")
test_case1.py:19: note: Following member(s) of "Bar" have conflicts:
test_case1.py:19: note:     __slots__: expected "Tuple[]", got "Tuple[str]"

The "fix" is to provide Tuple[str, ...] as the type for __slots__:

# test_case2.py
from __future__ import annotations
from typing import Protocol, Tuple, runtime_checkable

@runtime_checkable
class Foo(Protocol):
    __slots__: Tuple[str, ...] = ()
    def foo(self):
        ...

class Bar:
    __slots__ : Tuple[str, ...] = ("_t",)
    def __init__(self):
        self._t = True
    def foo(self):
        pass

print(f"isinstance(Bar(), Foo) == {isinstance(Bar(), Foo)}")  # still True
foo: Foo = Bar()  # <- works now?

% mypy --config-file=/dev/null test_case2.py
/dev/null: No [mypy] section in config file
Success: no issues found in 1 source file

Shouldn't mypy already know the type of __slots__?

[posita]

Here's another oddity not fixed by typing __slots___:

# test_case3.py
from fractions import Fraction
from typing import Protocol, Tuple, TypeVar, runtime_checkable
_T_co = TypeVar("_T_co", covariant=True)

@runtime_checkable
class RationalInitializerT(Protocol[_T_co]):
    __slots__: Tuple[str, ...] = ()
    def __call__(self, numerator: int, denominator: int) -> _T_co:
        ...

f: RationalInitializerT = Fraction  # <- errors

% mypy --config-file=/dev/null test_case3.py
/dev/null: No [mypy] section in config file
test_case3.py:12: error: Incompatible types in assignment (expression has type "Type[Fraction]", variable has type "RationalInitializerT[Any]")
Found 1 error in 1 file (checked 1 source file)

Now, remove __slots__:

# test_case4.py
from fractions import Fraction
from typing import Protocol, Tuple, TypeVar, runtime_checkable
_T_co = TypeVar("_T_co", covariant=True)

@runtime_checkable
class RationalInitializerT(Protocol[_T_co]):
    # __slots__: Tuple[str, ...] = ()  # <- commented out
    def __call__(self, numerator: int, denominator: int) -> _T_co:
        ...

f: RationalInitializerT = Fraction  # <- works now?

% mypy --config-file=/dev/null test_case4.py
/dev/null: No [mypy] section in config file
Success: no issues found in 1 source file

---

Another example:

# test_case5.py
from typing import Callable, Iterable, Protocol, Tuple, Union, runtime_checkable
from mypy_extensions import VarArg

@runtime_checkable
class ProcessorT(Protocol):
    __slots__: Tuple[str, ...] = ()
    def __call__(
        self,
        *inputs: int,
    ) -> Union[int, Iterable[int]]:
        ...

def narrower_return_proc(*inputs: int) -> Iterable[int]:
    return inputs

proc1: Callable[[VarArg(int)], Union[int, Iterable[int]]] = narrower_return_proc  # <- works
proc2: ProcessorT = narrower_return_proc  # <- errors

% mypy --config-file=/dev/null test_case5.py
/dev/null: No [mypy] section in config file
test_case5.py:18: error: Incompatible types in assignment (expression has type "Callable[[VarArg(int)], Iterable[int]]", variable has type "ProcessorT")
Found 1 error in 1 file (checked 1 source file)

Removing/commenting out __slots__ in the above example results in no errors.

[posita]

BTW, adding __slots__ to a Protocol doesn't seem that strange, since one might want to subclass it, and it seems to enjoy standard(ish) practice, given this [source]:

@runtime_checkable
class SupportsInt(Protocol):
    """An ABC with one abstract method __int__."""
    __slots__ = ()

    @abstractmethod
    def __int__(self) -> int:
        pass

But then I found this [source]:

def runtime_checkable(cls: _TC) -> _TC: ...
@runtime_checkable
class SupportsInt(Protocol, metaclass=ABCMeta):
    @abstractmethod
    def __int__(self) -> int: ...

I guess that's another way to "work around" trivial versions of the above problem, but it's not accessible (much less intuitive). I also have no idea how to make it work with forward references without reproducing entire swaths of code in .pyi files. For example:

# foo.py
from __future__ import annotations
from typing import Iterable, Protocol, Tuple, Union, runtime_checkable

class Foo:
    ...  # lots of of members and methods here

@runtime_checkable
class FooProcessorT(Protocol):
    __slots__: Tuple[str, ...] = ()
    def __call__(
        self,
        *inputs: Foo,
    ) -> Union[Foo, Iterable[Foo]]:
        ...

# foo.pyi
from __future__ import annotations
from typing import Protocol, Iterable, Union, runtime_checkable
from abc import ABCMeta

# What do I do? Redefine all of Foo's interfaces here?

@runtime_checkable
class FooProcessorT(Protocol, metaclass=ABCMeta):
    def __call__(
        self,
        *roll_outcomes: "Foo",  # <- undefined name 'Foo'
    ) -> Union["Foo", Iterable["Foo"]]:  # <- undefined name 'Foo'
        ...

What blows my mind is that this discovery makes the Protocols in typing.py look like a lie (at least with respect to Mypy)? I'm curious why "types" defined in typing.py would ever need ("clarifying"?) definitions in typing.pyi. Doesn't that kind of defeat the point?

[posita]

I found another case for which I cannot find a work-around, specifically where __slots__ for the value's type doesn't precisely match __slots__ for the protocol's type:

# test_case.py
from abc import abstractmethod
from typing import Any, Iterable, Protocol, Tuple, Union, runtime_checkable


class Foo:
    __slots__ = ("bar", "baz")

    def foo(self) -> None:
        pass


@runtime_checkable
class SupportsFoo(Protocol):
    __slots__: Union[
        str,
        Tuple[str],
        Tuple[str, str],
        Tuple[str, str, str],
        Tuple[str, ...],
        Iterable[str],
        Any,  # <-- adding this doesn't even help
    ] = ()

    @abstractmethod
    def foo(self) -> None:
        pass


@runtime_checkable
class SupportsFooExactMatchWorks(Protocol):
    __slots__: Tuple[str, str] = ()  # type: ignore

    @abstractmethod
    def foo(self) -> None:
        pass


@runtime_checkable
class SupportsFooAnyWorks(Protocol):
    __slots__: Any = ()

    @abstractmethod
    def foo(self) -> None:
        pass


v1: SupportsFoo = Foo()  # <-- error
v2: SupportsFooExactMatchWorks = Foo()  # works: precise type match on __slots__
v3: SupportsFooAnyWorks = Foo()  # works: __slots__: Any, and nothing else

% mypy --config-file=/dev/null test_case.py
/dev/null: No [mypy] section in config file
test_case.py:48: error: Incompatible types in assignment (expression has type "Foo", variable has type "SupportsFoo")
test_case.py:48: note: Following member(s) of "Foo" have conflicts:
test_case.py:48: note:     __slots__: expected "Union[str, Tuple[str], Tuple[str, str], Tuple[str, str, str], Tuple[str, ...], Iterable[str], Any]", got "Tuple[str, str]"
Found 1 error in 1 file (checked 1 source file)

What this effectively means is that if Protocols define __slots__ they must be explicitly typed as Any and nothing else. That seems wrong.

Collecting related issues:

#11821 (marked as fixed)
#11885 (still in draft, blocked on #11891)