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

[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)