Protocols should not care if a type is a class or an instance

[chadrik]

As a developer of a protocol, I don't care whether that protocol is met by an instance or a class, as long as the necessary functions and variables are present and correct. Currently it appears that only instances can satisfy a protocol.

For example, the code below attempts to meet a protocol using an instance and a class. It executes in python fine, but mypy complains that Type[Jumper1] is not compatible with the Jumps protocol:

from typing_extensions import Protocol

class Jumps(Protocol):
    def jump(self) -> int:
        pass

class Jumper1:
    @classmethod
    def jump(cls) -> int:
        print("class jumping")
        return 1

class Jumper2:
    def jump(self) -> int:
        print("instance jumping")
        return 2

def do_jump(j: Jumps):
    print(j.jump())

do_jump(Jumper1)
do_jump(Jumper2())

[glyph]

I just hit this as well. It looks like this and #5018 are the same issue, but about modules rather than classes.

I think the same thing probably should be true of instances as well. If I do, for example:

class Empty: pass
nothing = Empty()
def free_jump() -> int:
    return 3
nothing.jump = free_jump
do_jump(nothing)

I feel like that ought to work.

Zope Interface has this notion of "provides" as distinct from "implements" to draw a clean separation between the different ways a type can relate to an Interface; it seems like Protocol should behave in the same way. It has a directlyProvides function which can be used to annotate any object, including classes and modules, to indicate that it provides the interface.

[gvanrossum]

I agree with the OP's initial example (and with #5018), but I think Glyph's example goes a bit too far -- it dynamically modifies an object. While in the toy example it is easy to see that nothing has a jump attribute, in realistic applications I doubt that in most cases mypy would be able to make the connection.

IIUC the provides/implements distinction is between a class whose instances can jump() vs. an instance that can jump()? (Though I'm not all that familiar with Zope Interface, and the two words don't have clearly distinct meanings to me -- I could easily have it backwards.)

[ilevkivskyi]

I agree with the OP's initial example (and with #5018), but I think Glyph's example goes a bit too far

The same for me.

[ilevkivskyi]

Note to self: we need to add an OP example (simplified) to the PEP 544 (there is already a PR for modules).

[glyph]

IIUC the provides/implements distinction is between a class whose instances can jump() vs. an instance that can jump()?

Yes.

To restate:

An object x is said to "provide" the interface IX if a function that "takes an IX" can take x and behave correctly; i.e. it matches the specification presented by IX.

A type X is said to "implement" the interface IX if all its instances provide IX.

The distinction is important because if IX specifies methods a, b, and c, the type X might:

• have all three of those attributes just because it implements the interface, but this of course doesn't imply that it provides said interface,
• implement the interface using some runtime trickery and not itself have any of those attributes,
• have all three of those attributes because it directly provides the interface; if it does so, depending on descriptor semantics, its instances may or may not provide the interface; i.e. it may provide but not implement the interface.

[glyph]

Regarding my setting-attributes-on-an-instance example, I agree that as stated it's perhaps pushing mypy a bit far. Practically I do not expect it to be able to do that automatically without help. What I want is maybe something like dynamic_cast in C++, for @runtime Protocols only.

[gvanrossum]

OK, so "provides" is a property of objects while "implements" is a property of types -- with the understanding that a class is both an object and a type. And the distinction is an important once especially when you're doing runtime checking and all you can check is the presence of specific attributes, rather than the full signatures of methods.

(I've got to admit that even after writing that down the choice of terms still feels a bit arbitrary. Especially "implements" could go either way in my intuition.)

In general the checks that mypy performs are about "provides" -- e.g. we have a function foo:

class P(Protocol): ...
def foo(arg: P):
    ...

and we're calling it with an expression:

foo(expr)

then mypy checks whether expr provides P. In the usual case, this boils down to checking whether the type of expr implements P.

But when expr is a class object, checking whether that class provides P roughly requires looking for matches of P's methods among that class's class methods and static methods. (We should first check whether its metaclass implements P, given that classes are objects.)

Finally when expr is a module object we should again check whether the module provides P by matching the functions it defines against the methods of P (again after checking whether ModuleType might implement P).

I suppose in the wonderful world of Zope Interfaces there are other cases to consider, since providing an interface could be done dynamically. But mypy is no help here, and I think the examples of dynamically providing an interface that I've seen all deserve the term "hack". :-)