How do I type hint a static method as a class (static) attribute?

[BaconPancakes]

I want to define an interface for defining methods associated with a class that corresponds to a Callable signature defined elsewhere. How can I get the following to work?

Code sample in pyright playground

from typing import Callable, Protocol


type FooFun = Callable[[int], int]

class MyInterface(Protocol):
    function: FooFun

class MyConcrete(MyInterface):
    @staticmethod
    def function(my_int: int) -> int: # Base method is declared as an instance method but override is not
        return my_int

class MySecondConcrete(MyInterface):
    def function(self, my_int: int) -> int: # Positional parameter count mismatch; base method has 1, but override has 2
        return my_int

Of course, there is also the conventional option of just simply using regular static method function signatures (def), but is there a way to do with Callable attributes?

[erictraut]

If I understand you correctly, you want to define some protocol MyInterface such that both MyConcrete and MySecondConcrete are considered compatible with this protocol. Here's how I'd do this:

from typing import Protocol

class MyInterface(Protocol):
    def function(self, my_int: int) -> int: ...

class MyConcrete:
    @staticmethod
    def function(my_int: int) -> int:
        return my_int

class MySecondConcrete:
    def function(self, my_int: int) -> int:
        return my_int

x1: MyInterface = MyConcrete()
x2: MyInterface = MySecondConcrete()

Note that in my formulation, the two concrete classes don't directly inherit from the protocol. This allows them to match the protocol without resulting in override violations. Override checks are necessarily more strict than protocol matching because a subclass might be used as either a class object or a class instance, and it needs to follow the LSP (Liskov Substitution Principle) in both cases. A protocol simply needs to work with class instances.

I'll note that protocol matching rules are clearly defined in the typing spec. However, the typing spec doesn't currently define the rules for overrides. It's an area where additional work is needed. That said, I think pyright's override rules in this case are defensible and correct from a typing perspective.

[rayansostenes]

I had a similar problem a while ago. The problem with not inheriting from the Protocol is that we lose the type errors on the definition, errors will appear only on the places where you are using the protocol.
My solution was to create a simple decorator, to force type checking of the concrete class.

def implements[T](protocol: type[T]):
    def decorator(cls: type[T]):
        return cls

    return decorator

On the examples bellow we get no errors:

class MyInterface(Protocol):
    def function(self, my_int: int) -> int: ...


@implements(MyInterface)
class MyConcrete:
    @staticmethod
    def function(my_int: int) -> int: ...


@implements(MyInterface)
class MySecondConcrete:
    def function(self, my_int: int) -> int: ...


@implements(MyInterface)
class MyThirdConcrete:
    @classmethod
    def function(cls, my_int: int) -> int: ...

But we get a type error if we incorrectly implement the interface

@implements(MyInterface)
class InvalidImplementation:
    def function(self, my_int: int) -> str: ...
                                     # ^^^
                                     # Note the return type here

The above code would generate the following type error:

Argument of type "type[InvalidImplementation]" cannot be assigned to parameter "cls" of type "type[MyInterface]" in function "decorator"
  "InvalidImplementation" is incompatible with protocol "MyInterface"
  Type "type[InvalidImplementation]" is not assignable to type "type[MyInterface]"
    "function" is an incompatible type
      Type "(my_int: int) -> str" is not assignable to type "(my_int: int) -> int"
        Function return type "str" is incompatible with type "int"
          "str" is not assignable to "int"

The downside is that the error, appear on the decorator line, not on the def function line, but it's good enough for my use case.

[BaconPancakes]

My goal is to define a Protocol interface with a Callable attribute that might be satisfied by an implementation's def statement. After using your tip about not inheriting directly from the Protocol along with making the protocol member immutable, the following example does work (albeit with some inconvenient loss in type checking as @rayansostenes pointed out)

Code sample in pyright playground

from typing import Callable, Protocol

type FooFun = Callable[[int], int]

class MyInterface(Protocol):
    @property
    def function(self) -> FooFun:
        ...

class MyConcrete():
    @staticmethod
    def function(my_int: int) -> int:
        return my_int

def my_caller(interface: MyInterface):
    interface.function(1)

my_caller(MyConcrete())

So then the question with regards to stricter override checks is then, why is a function definition not allowed to override an immutable Callable attribute?

Code sample in pyright playground

from typing import Callable, Protocol

type FooFun = Callable[[int], int]

class MyInterface(Protocol):
    @property
    def function(self) -> FooFun:
        ...

class MyConcrete(MyInterface):
    @staticmethod
    def function(my_int: int) -> int: # "function" incorrectly overrides property of same name in class "MyInterface"
        return my_int

def my_caller(interface: MyInterface):
    interface.function(1)
    
my_caller(MyConcrete())

Is the above an unsafe override?

[BaconPancakes]

I know the obvious solution is to just use a normal def

class MyInterface(Protocol):
    def function(self, my_int: int) -> int: ...

and this will work, but I was just exploring the option of using Callable attributes as flexible alternative.

[erictraut]

why is a function definition not allowed to override an immutable Callable attribute?

As I mentioned above, overrides need to honor the LSP regardless of whether you access the attribute from the class object or from an instance of that class. This is required because Child is a subtype of Parent and type[Child] is a subtype of type[Parent].

from typing import Callable, reveal_type

class Parent:
    a: Callable[[int], int] = lambda x: x

    def __init__(self):
        self.a = lambda x: x

    @property
    def b(self) -> Callable[[int], int]:
        return lambda x: x

    def c(self, v: int, /) -> int:
        return v

class Child(Parent):
    @staticmethod
    def a(v: int, /) -> int:
        return v

    @staticmethod
    def b(v: int, /) -> int:
        return v

    @staticmethod
    def c(v: int, /) -> int:
        return v

# These work fine
reveal_type(Parent().a)  # (int) -> int
reveal_type(Parent().b)  # (int) -> int
reveal_type(Parent().c)  # (int) -> int
Parent().a(1)  # OK
Parent().b(1)  # OK
Parent().c(1)  # OK

reveal_type(Child().a)  # (int) -> int
reveal_type(Child().b)  # (int) -> int
reveal_type(Child().c)  # (int) -> int
Child().a(1)  # OK
Child().b(1)  # OK
Child().c(1)  # OK

# These do not work

reveal_type(Parent.a)  # (int) -> int
reveal_type(Parent.b)  # property
reveal_type(Parent.c)  # (self: Parent, v: int, /) -> int
Parent.a(1)  # OK
Parent.b(1)  # Crash
Parent.c(1)  # Crash

reveal_type(Child.a)  # (int) -> int
reveal_type(Child.b)  # (int) -> int
reveal_type(Child.c)  # (int) -> int
Child.a(1)  # OK
Child.b(1)  # OK
Child.c(1)  # OK