@implements(Protocol)
decorator possible without Higher Kinded Types?
#1943
-
Sometimes I wish I there was a decorator class MyProtocol(Protocol): ...
@implements(MyProtocol)
class MyImplementation: ... Currently, the workaround I am using is writing static tests like Question: Am I overlooking something, or is it currently impossible to implement Here's what I think it should look like: def implements[T](proto: type[T]) -> ???:
# here, we want the identity function on the set of subtypes of T
def decorator[C: type[T]](cls: C) -> C:
return cls
return decorator I believe we need the dependent type |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Indeed, this does appear impossible without HKTs or a dedicated mypy plugin, like But it seems to me like first-class support for a decorator like this seems preferable over a generic approach using HKTs, purely due to the quality of the error messages you're likely to get out of it. Like a non-generic version of this currently does:
It doesn't tell you what attributes/methods are missing or incorrect, so not very helpful at all. Although to be fair, it also doesn't tell you in an |
Beta Was this translation helpful? Give feedback.
Indeed, this does appear impossible without HKTs or a dedicated mypy plugin, like
mypy-zope
which does provide support forzope.interface
'sInterface
objects as types and its@implementer
decorator.But it seems to me like first-class support for a decorator like this seems preferable over a generic approach using HKTs, purely due to the quality of the error messages you're likely to get out of it. Like a non-generic version of this currently does:
It doesn't tell you what attributes/methods are missing or incorrect, so not very helpful at all. Although to be fair, it also doesn't tell you in an
x: type[Proto] =…