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.

[rayansostenes]

@JelleZijlstra, thanks for the fast response, I found a nicer alternative to do what I wanted in the first place.
(Give type errors for Protocol implementations at the class definition site, and not only when instantiating the class).

# /tmp/t.py
from typing import Protocol

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


def implements_my_protocol[P: MyProtocol](cls: type[P]) -> type[P]:
    return cls


@implements_my_protocol
class Concrete:
    ...

$ npx pyright /tmp/t.py
/tmp/t.py
  /tmp/t.py:13:2 - error: Argument of type "type[Concrete]" cannot be assigned to parameter "cls" of type "type[P@implements_my_protocol]" in function "implements_my_protocol"
    Type "Concrete" is incompatible with type "MyProtocol"
      "Concrete" is incompatible with protocol "MyProtocol"
        "my_method" is not present (reportArgumentType)
1 error, 0 warnings, 0 informations 

Although it would nicer if python supported generic upper bounds, Then I could have a generic function that would work for all Protocols, something like:

def implements_protocol[P, T: P](protocol_type: type[P]) -> Callable[[type[T]], type[T]]:
    def wrapper[T: P](cls: type[T]) -> type[T]:
        return cls
    return wrapper

In typescript we can do something similar using the extends keyword, but there we have
the implements keyword that does exactly what I want.

interface MyInterface {
    myMethod(): void;
}

class MyClass {}

function implementsInterface<P>() {
    return function <T extends { new (): P }>(target: T) {
        return target;
    };
}
implementsInterface<MyInterface>()(MyClass);
// Argument of type 'typeof MyClass' is not assignable to parameter of type 'new () => MyInterface'.
//   Property 'myMethod' is missing in type 'MyClass' but required in type 'MyInterface'

class MyOtherClass implements MyInterface {}
// Class 'MyOtherClass' incorrectly implements interface 'MyInterface'.
//   Property 'myMethod' is missing in type 'MyOtherClass' but required in type 'MyInterface'

[JelleZijlstra]

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.

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