Repository navigation
feature: Support for Pre-PEP 695 generics #405
Description
Activity
Thanks for the feature request @jonathan-laurent 🙂
Now that Griffe models support type parameters, it shouldn't be too hard to parse
Genericin class bases to extract the type parameters, associating them with declared attributes of the same name 👍I'd be interested in this feature too.
I just discovered this Type Parameters section, which seemed like a big improvement to my informal version in some protocols:
Show diff
diff --git a/src/narwhals/_plan/compliant/plugins.py b/src/narwhals/_plan/compliant/plugins.py index 93907fa1f..5b330bba1 100644 --- a/src/narwhals/_plan/compliant/plugins.py +++ b/src/narwhals/_plan/compliant/plugins.py @@ -50,7 +50,11 @@ __all__ = ("Builtin", "Implementation", "Plugin") class Plugin(HasClasses[C], Protocol[C, DF, LF, S]): """An entrypoint for a backend that implements compliant-level operations. - `[C, DF, LF, S]`. + Type Parameters: + C: _description_ + DF: _description_ + LF: _description_ + S: _description_ """
But that's triggering the same path:
Show logs
griffe: src\narwhals\_plan\compliant\plugins.py:54: Type parameter 'C' does not appear in the class signature griffe: src\narwhals\_plan\compliant\plugins.py:55: Type parameter 'DF' does not appear in the class signature griffe: src\narwhals\_plan\compliant\plugins.py:56: Type parameter 'LF' does not appear in the class signature griffe: src\narwhals\_plan\compliant\plugins.py:57: Type parameter 'S' does not appear in the class signatureAnyways - just here to say you might need to handle
Protocolas a special-case too 🙂:from typing import Generic, Protocol, TypeVar, is_protocol T = TypeVar("T") class This(Protocol[T]): member: T class AndThis(Generic[T], Protocol): # noqa: PYI059 member: T class ButAlso(Protocol, Generic[T]): member: T is_protocol(This), is_protocol(AndThis), is_protocol(ButAlso)
(True, True, True)
Context and Problem
I saw there was a debate on a recently merged PR about whether or not to support pre-PEP 695 generics (i.e., which use
GenericandTypeVar).My understanding is that these are not currently supported. One particular consequence are spurious warnings. For example, for the following class definition:
I get the spurious warning:
The Case for Supporting Pre-PEP 695 Generics
One argument for supporting pre-PEP 695 generics is that the features they offer are not subsumed by PEP 695. In particular, PEP 695 does not allow specifying the variance of type variables. Type checkers can infer this information most of the time, but there are also cases where the use of
TypeVarandGenericcannot be avoided (this is the case in one of my projects).If (partial) support for Pre-PEP 695 Generics can be added without excessive effort, it would therefore be a worthwhile addition.