Description

AlexWaygood

opened on Mar 9, 2023

Issue body actions

Consider the snippet below:

from typing import runtime_checkable, Protocol

@runtime_checkable
class HasX(Protocol):
    x: int

class HasNothingButSlots:
    __slots__ = ("x",)

def requires_object_with_x(obj: HasX) -> None:
    print(obj.x)

requires_object_with_x(HasNothingButSlots())

Mypy does not see HasNothingButSlots as a valid subtype of of HasX, so complains about this code. Pyright, however, does see HasNothingButSlots as a valid subtype of HasX, so has no complaints.

Currently, the runtime agrees with mypy: calling isinstance(HasNothingButSlots(), HasX) evaluates to False (due to the fact that the x variable has not been initialised on the instance). If we implement any of the patches discussed in #1363, this will change, and the runtime will agree with pyright: isinstance(HasNothingButSlots(), HasX) will evaluate to True even if the x variable has not been initialised on the instance.

Who is correct: mypy or pyright?

Activity

1. AlexWaygood

   added

   topic: otherOther topics not coveredOther topics not covered

   on Mar 9, 2023
2. AlexWaygood

   changed the title [-]How should structural subtyping work for objects with slots?[/-] [+]How should structural subtyping work for objects with slots but no variable declarations?[/+] on Mar 9, 2023
3. TeamSpen210 commented on Mar 9, 2023

   

   TeamSpen210

   on Mar 9, 2023

   More actions

   Perhaps it would be reasonable for mypy to treat this as x: Any, but also produce a "x needs a type definition" or "Any type inferred" warning?

   Reacted by Alex Waygood and Siddhartha Gandhi
4. gvanrossum commented on Mar 10, 2023

   

   gvanrossum

   on Mar 10, 2023

   Member

   More actions

   I tend to agree with pyright -- surely any realistic class with slots does initialize the slots in __init__ or some other method?

   Reacted by Alex Waygood
5. AlexWaygood commented on Mar 12, 2023

   

   AlexWaygood

   on Mar 12, 2023

   MemberAuthor

   More actions

   The points made here makes sense to me. Seems like the consensus is that pyright's behaviour is preferable — closing as resolved.
6. AlexWaygood

   closed this as completedon Mar 12, 2023

Issue actions