Specializing generic class over ParamSpec

[raphCode]

Bug Report

I tried to be too clever and wanted to feed the signature of an existing function in a generic class. The goal is to specialize the class for different signatures.*
I invested quite some time trying, but It always failed in funny ways.
I realize that this is probably not intended to work, but I could not find any information in the mypy / python typing docs which explicitly forbids this. I am therefore not sure if this is a mypy or documentation issue.

I want to share my results here. Maybe they are useful as a test scenario or for discovering bugs.

To Reproduce

Common setup, shared with all examples:

from typing import *

P = ParamSpec("P")
R = TypeVar("R", covariant=True)

def forward(a: int, b: str) -> float:
    return 0.0

class Proto(Generic[P, R], Protocol):
    def forward(self, *args: P.args, **kwargs: P.kwargs) -> R:
        pass

    def default_implementation(self, *args: P.args, **kwargs: P.kwargs) -> R:
        return cast(R, ...)

Attempt 1: Custom generic class (playground)

class MetaProto(type):
    def __getitem__(cls, item: Callable[P, R]) -> Type[Proto[P, R]]:
        return Proto[P, R]

class ProtoFactory(metaclass=MetaProto):
    pass

reveal_type(ProtoFactory[forward])  # works

class A(ProtoFactory[forward]):  # fails: error
    pass

note: Revealed type is "Type[Proto[[a: builtins.int, b: builtins.str], builtins.float]]"
error: "ProtoFactory" expects no type arguments, but 1 given  [type-arg]
error: Function "forward" is not valid as a type  [valid-type]

Attempt 2: Class decorator (playground)

C = TypeVar("C")

class MakeProto(Generic[P, R]):
    def __init__(self, a: Callable[P, R]):
        pass

    def __call__(self, wrapped: Type[C]) -> Type[Proto[P, R]]:
        return Proto[P, R]

class A:
    pass
reveal_type(MakeProto(forward)(A))  # works

@MakeProto(forward)  # fails: decorator changes nothing
class B:
    pass
reveal_type(B)

note: Revealed type is "Type[Proto[[a: builtins.int, b: builtins.str], builtins.float]]"
note: Revealed type is "def () -> B"

Expected Behavior

No errors, inheritance from the specialized Protocol.
See also the lines with # works comments.

Additional comments

*I am aware of some alternatives:

• per-method signature copy decorator
  My current workaround, using a hand-written class specialized for every signature I want to use. I write one method and copy the signature over to the others.
  The problem is, I have to repeat this for every method in every class instead of just specializing the generic class multiple times.
• Specializing a class generic over TypeVarTuple / ParamSpec with a tuple of argument types:
  This unfortunately does not capture positional argument names

My use case is related to PyTorch: Modules implement a forward() method, but are called using a superclass's __call__(), which does not know anything about the forward()'s signature. I want to write an abstract base class that:

• enforces a signature for implementors on forward()
• provides the same signature in __call__() to typecheck the usage outside of the module
• provides a new method which also shares forward()'s signature

Your Environment

• Mypy version used: 1.2.0
• Python version used: 3.11

[raphCode]

I realized, instead of trying to pass an existing function, I could also pass a Protocol which implements __call__().
That seems to be accepted better by mypy since the error Function "forward" is not valid as a type [valid-type] disappears. Not sure if passing functions directly is also supposed to work?

However, there are still two bugs in mypy which block me from achieving my goal or testing any further:

• Custom generics can't be used at all, I opened an additional issue at metaclasses implementing __getitem__ work only in reveal_type(), cannot be used anywhere #15107
• In the case of class decorators, nothing happens, tracked here: class decorators that change the type don't work #11117

[erictraut]

Functions cannot be used as type arguments to a generic class in the current Python static type system, so "Attempt 1" will not work.

"Attempt 2" doesn't look like it will work at runtime, at least not as it's currently implemented, because MakeProto.__call__ is returning a protocol class, which can't be instantiated at runtime. Otherwise it looks like this should work. The problem is that mypy doesn't currently honor class decorators; it simply ignores them. Unless/until that bug is fixed, this approach won't work in mypy. It works in pyright, which does honor class decorators.

I don't see anything else actionable in the bug report, so I think it can be closed.