assignability of class literals or type[] types to a protocol

[carljm]

This example is adapted from https://typing.python.org/en/latest/spec/protocol.html#type-and-class-objects-vs-protocols

from typing import Any, Protocol

class ProtoA(Protocol):
    def meth(self, x: int, /) -> int: ...
class ProtoB(Protocol):
    def meth(self, obj: Any, x: int, /) -> int: ...

class C:
    def meth(self, x: int, /) -> int: ...

a: ProtoA = C  # should fail
b: ProtoB = C  # should pass
def _(tc: type[C]):
    b2: ProtoB = tc  # should pass

In ty, all three of these assignments currently fail.

[AlexWaygood]

note that we only emit an error for a protocol with method members. If the protocol has property or attribute members, we have the expected behaviour:

from typing import Any, Protocol, Callable

class ProtoA(Protocol):
    x: int

class ProtoB(Protocol):
    x: str

class C:
    x = 42

c: ProtoA = C  # no error
d: ProtoB = C  # error, as expected

def _(tc: type[C]):
    b2: ProtoA = tc  # no error
    b3: ProtoB = tc  # error, as expected

and we also do not error if the class has a metaclass that defines the method:

from typing import Any, Protocol

class ProtoA(Protocol):
    def meth(self, x: int, /) -> int: ...

class ProtoB(Protocol):
    def meth(self, obj: Any, x: int, /) -> int: ...

class Meta(type):
    def meth(self, x: int, /) -> int:
        return 42

class C(metaclass=Meta): ...

a: ProtoA = C  # no error
b: ProtoB = C  # fails, as expected

def _(tc: type[C]):
    b2: ProtoA = tc  # no error
    b3: ProtoB = tc  # fails, as expected

So this is really the same as #931: we impose extra restrictions on assignability with respect to protocols with method members in order to emulate the way Python looks up methods as descriptors on the type of an object, and in order to make type[P] sound where P is a protocol. (We say that a method member m must exist on C's meta-type as well as on instances of C in order for C to satisfy a protocol P that includes m in its interface.) But this runs afoul of the spec, because the spec mandates unsound behaviour for these cases.

Attempting to make our behaviour sound may just not be worth it here; we may have to relax this restriction and just do what other type checkers do.

[sid-kap]

@AlexWaygood I'm a little confused about the soundness part, why is the spec behavior unsound? (Why is it important to require that the method has to exist on the type of the object?)

[carljm]

@AlexWaygood I'm a little confused about the soundness part, why is the spec behavior unsound? (Why is it important to require that the method has to exist on the type of the object?)

Because of the way type checkers treat type[P] where P is a protocol -- they assume it has the methods defined on P. The other (sound) option would be to treat type[P] as having only thing explicitly annotated as ClassVar on the protocol, and don't include methods in that set.