Does assert_type is supposed to work with Protocol?

[rayansostenes]

Does assert_type only supports nominal types?
I'm trying to use it to check a Protocol but it does not work.

from typing import Protocol, assert_type

class MyProtocol(Protocol):
    def my_method(self) -> None:
        ...

class Concrete:
    def my_method(self) -> None:
        ...

x: MyProtocol = Concrete() # OK
assert_type(Concrete(), MyProtocol) # "assert_type" mismatch: expected "MyProtocol" but received "Concrete" 

Pyright Playground Link

MyPy has a similar error:

error: Expression is of type "Concrete", not "MyProtocol"  [assert-type]

Also, I tried to find any documentation about how assert_type is supposed to work, but I did not found a PEP or something similar explaining it. Does this exists anywhere?

[JelleZijlstra]

assert_type() works with protocols, but it checks for an exact match, not for assignability. To check that Concrete is assignable to MyProtocol, it is enough to do e.g. x: MyProtocol = Concrete().

There is a specification at https://typing.readthedocs.io/en/latest/spec/directives.html#assert-type but it could be made more precise.

[maflAT]

You can add the protocol to your base classes, and the type checker will tell you if you're not implementing the protocol correctly.

This is not entirely true.
For example, a concrete class with a normal attribute will be compatible with a protocol, that defines the same attribute as a property.
However, if I use that protocol as a base for my concrete class, pyright will complain that I am incorrectly overriding that attribute.

Although I'm not sure if this is intended behavior or an oversight.

[erictraut]

...pyright will complain that I am incorrectly overriding that attribute. ...I'm not sure if this is intended behavior or an oversight.

This is intended behavior, although it admittedly falls into an area of the typing spec that is currently unspecified. Overload rules are an area I'd like to see us standardize eventually.

I think it would also be a good idea to extend the usage of the ReadOnly directive (recently introduced in PEP 705) to protocols so developers don't need to resort to using properties to specify a read-only attribute in protocols. This has always seemed like a hack to me. Properties are descriptor objects. The semantics of a property is similar to that of a simple class variable, but the behaviors diverge when accessed from the class object. For this reason, pyright treats them as incompatible when validating override compatibility.

[guillaume-mueller]

we have the implements keyword that does exactly what I want

Python has that too! You can add the protocol to your base classes, and the type checker will tell you if you're not implementing the protocol correctly. That does mean you also add a runtime base, though.

@JelleZijlstra

What do you mean by "add the protocol to your base classes"? If my concrete class inherits from the my template/protocol class, Pyright doesn't complain if not all my methods are present. I have to do a runtime x: MyProtocol = Concrete() to get it complaining.

MRE:

from typing import Protocol

class MyProtocol(Protocol):
    def required_method(self):
        ...

class MyClass(MyProtocol):
    ...

# I have to add this line to get Pyright complaining
_: MyProtocol = MyClass()

[erictraut]

If you want pyright to report missing methods in MyClass in this case, you'd need to mark MyClass as @final. Without the @final, it can be used as an (abstract) base class for other classes, so it's not appropriate to report errors for missing methods unless/until you attempt to instantiate it.

[guillaume-mueller]

It works, thanks !