You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document that inspect.isclass returns False for GenericAlias instances #132467
importinspectfromtypingimportTypeVar, GenericT=TypeVar("T")
classNode(Generic[T]):
x: T# Instance attribute (see below)def__init__(self, label: T|None=None) ->None:
self.label=labelx=Node("") # Inferred type is Node[str]y=Node(0) # Inferred type is Node[int]z=Node() # Inferred type is Node[Any]# Also OK:y=Node[int](0)
print(inspect.isclass(Node)) # Trueprint(inspect.isclass(Node[int])) # False (shouldn't this be True?)print(inspect.isclass(Node[str])) # False (shouldn't this be True?)
In the example above, shouldn't calls such as inspect.isclass(Node[int]) return True, since they can be instantiated and used like normal classes?
I would regard Node[int] as the specialization of a generic class (similar to specialization of a C++ template class or Java/TypeScript generics), hence a class. The docs also say (emphasis mine):
Note that the runtime type (class) of p and q is still just Node – Node[int] and Node[str] are distinguishable class objects, but the runtime class of the objects created by instantiating them doesn’t record the distinction.
So according to this, inspect.isclass() should indeed return True. However, at runtime, Node[int] is a GenericAlias instance so should it still be considered a class? I don't have an answer to this question but I'd like to point that changing the behavior of inspect.isclass may cause downstream issues where one would not expect to filter GenericAlias objects.
changed the title [-]inspect.isclass returns False for user-defined Generics[/-][+]inspect.isclass returns False for `GenericAlias` instances[/+]on Apr 13, 2025
The behaviour here is correct. You can see #89828, and its many linked sub-issues, for the various bugs that can be caused if GenericAlias instances are considered exactly equivalent to classes at runtime.
I'd be open to making an improvement to the docs somewhere if the current docs are confusing, however!
I also agree that changing anything in inspect.is* can break a lot of code. And it is easier to adapt any checks in your own code: inspect.isclass(obj) or isinstance(obj, GenericAlias) - for example.
I think we should improve the docs by saying that GenericAlias instances are not considered to be classes by inspect.isclass, although they behave as a class.
Note
For newcomers, they should update both the online docs (rst) and the docstring. If possible (and if this is not already the case), they could also add a test for that.
changed the title [-]inspect.isclass returns False for `GenericAlias` instances[/-][+]Document that `inspect.isclass` returns False for `GenericAlias` instances[/+]on Apr 13, 2025
@sobolevn: I also agree that changing anything in inspect.is* can break a lot of code. And it is easier to adapt any checks in your own code: inspect.isclass(obj) or isinstance(obj, GenericAlias) - for example.
isinstance(Node[int], GenericAlias) is also returning False:
# Definition of generic Node is same>>>inspect.isclass(Node[int])
False# ok>>>fromtypesimportGenericAlias>>>inspect.isclass(Node[int]) orisinstance(Node[int], GenericAlias)
False# ?>>>isinstance(Node[int], GenericAlias)
False# ?
Version: Python 3.14.0a7+, is that expected behaviour?
I see that, there was discussion about types.GenericAlias VS typing._GenericAlias. As I understand this is documented in code, should we document in online docs ?
Activity
picnixz commentedon Apr 13, 2025
I would regard
Node[int]as the specialization of a generic class (similar to specialization of a C++ template class or Java/TypeScript generics), hence a class. The docs also say (emphasis mine):So according to this,
inspect.isclass()should indeed return True. However, at runtime,Node[int]is aGenericAliasinstance so should it still be considered a class? I don't have an answer to this question but I'd like to point that changing the behavior ofinspect.isclassmay cause downstream issues where one would not expect to filterGenericAliasobjects.cc @JelleZijlstra
[-]inspect.isclass returns False for user-defined Generics[/-][+]inspect.isclass returns False for `GenericAlias` instances[/+]AlexWaygood commentedon Apr 13, 2025
The behaviour here is correct. You can see #89828, and its many linked sub-issues, for the various bugs that can be caused if
GenericAliasinstances are considered exactly equivalent to classes at runtime.I'd be open to making an improvement to the docs somewhere if the current docs are confusing, however!
sobolevn commentedon Apr 13, 2025
I also agree that changing anything in
inspect.is*can break a lot of code. And it is easier to adapt any checks in your own code:inspect.isclass(obj) or isinstance(obj, GenericAlias)- for example.picnixz commentedon Apr 13, 2025
I think we should improve the docs by saying that GenericAlias instances are not considered to be classes by
inspect.isclass, although they behave as a class.Note
For newcomers, they should update both the online docs (rst) and the docstring. If possible (and if this is not already the case), they could also add a test for that.
[-]inspect.isclass returns False for `GenericAlias` instances[/-][+]Document that `inspect.isclass` returns False for `GenericAlias` instances[/+]AbduazizZiyodov commentedon Apr 13, 2025
@sobolevn Can you assign me to this issue ? I will work on it
sobolevn commentedon Apr 13, 2025
@AbduazizZiyodov sure, please go ahead :)
AbduazizZiyodov commentedon May 3, 2025
isinstance(Node[int], GenericAlias)is also returningFalse:Version:
Python 3.14.0a7+, is that expected behaviour?AbduazizZiyodov commentedon May 3, 2025
But this behaves as expected:
I see that, there was discussion about
types.GenericAliasVStyping._GenericAlias. As I understand this is documented in code, should we document in online docs ?AbduazizZiyodov commentedon May 6, 2025
PRs #133504 , python/typing#1993
gh-132467: Document and test that generic aliases are not classes (#1…
[3.15] gh-132467: Document and test that generic aliases are not clas…
[3.14] pythongh-132467: Document and test that generic aliases are no…
[3.13] gh-132467: Document and test that generic aliases are not clas…
[3.14] gh-132467: Document and test that generic aliases are not clas…
pythongh-132467: Document and test that generic aliases are not class…
Merge pull request #1 from rohitjain25/clarify-generic-alias-isclass-…