`is_generic_type` is True for a non-generic Protocol

[kiran]

is_generic_type returns True for a non-generic Protocol:

Tested on Python 3.8.2 and Python 3.6.10:

from typing import Generic

from typing_extensions import Protocol, runtime
from typing_inspect import NEW_TYPING, get_parameters, is_generic_type

@runtime
class SomeProtocol(Protocol):
    def a_method(self) -> str:
        ...

assert is_generic_type(SomeProtocol)

if NEW_TYPING:
    assert isinstance(SomeProtocol, type)
    assert issubclass(SomeProtocol, Generic)
else:
    from typing import GenericMeta
    assert isinstance(SomeProtocol, GenericMeta)

# typing._check_generic raises 
# TypeError: <class '__main__.SomeProtocol'> is not a generic class
SomeProtocol[int] 

implementation of is_generic_type

[ilevkivskyi]

In some sense this is expected behavior. The term "generic" is overloaded, meaning both "this class can still be parameterized with type argument", and "this class has Generic in its (effective) MRO".

Consider this example:

from typing import TypeVar, Generic
T = TypeVar('T')
class C(Generic[T]):
    ... 
class D(C[int]):
    ...

is_generic_type(D) # True
D[int]  # TypeError: <class '__main__.D'> is not a generic class

So is_generic_type() means the second of the two meanings above. If you want the first one you should probably use get_parameters() and check it is non-empty.

[raabf]

I must agree that this is confusing. I can understand why in the example is_generic_type(D) == True, let me make another example:

Python 3.8.12 (default, Aug 31 2021, 01:23:42) [GCC] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import typing
>>> import typing_inspect
>>> typing_inspect.is_generic_type(typing.List)
True
>>> isinstance(typing.List, typing.Protocol)
True
>>> class UrlList(typing.List[str]):
...   ...
... 
>>> typing_inspect.is_generic_type(UrlList)
True
>>> typing_inspect.get_parameters(UrlList)
()

That typing_inspect.is_generic_type(UrlList) == True is OK – we all know that List is naturally a Generic type, in UrlList the item type is just difined as an URL represented as a str, not really a confusion. To check that it has any unused TypeVars by using typing_inspection.get_parameters is probably OK.

However, SomeProtocol just specify that a_method must be implemented to be a SomeProtocol, but never had some Generic parts (although technically it is a subclass of typing.Generic). That also true for some built-in stuff like typing.Hashable which is typing_inspect.is_generic_type(typing.Hashable) == True but just specify that an __hash__ method exists – never had any generic parts and it suprised me very much that this is generic.

Or in other words, probably the confusing this is that you can do:

>>> class P(typing.Protocol):  # No TypeVar is used!
...   ...
... 
>>> typing_inspect.is_generic_type(P)  # No TypeVar but it is a Generic!
True

and P is a generic type, but you cannot inherit Generic:

>>> class G(typing.Generic): # Also no TypeVar used!
...   ...
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.8/typing.py", line 908, in __init_subclass__
    raise TypeError("Cannot inherit from plain Generic")
TypeError: Cannot inherit from plain Generic

That is quite wired thing of the typing.Protocol class.

In some way the originating PEP544 underlines that, as it says:

Protocol[T, S, ...] is allowed as a shorthand for Protocol, Generic[T, S, ...].

Hence it is a convenient shorthand when a TypeVar is used, not that every Protocol is Generic (again although it is implemented in that way that every Protocol is a Generic).

I would feel better if typing_inspect.is_generic_type(SomeProtocol) would return False instead of True.

Mhmm or at least something like a function is_generic_and_has_used_type_var() which also checks for an used TypeVar (should be only the case with typing.Protocol, or are there other cases where you can inherit typing.Generic without using a TypeVar?)...

[ilevkivskyi]

FWIW I don't want to change the current behavior, because it would be back wards incompatible, but I think it is OK to add a second helper like is_generic_strict() that would specifically exclude cases where parameters are empty.