typing.is_typeddict returns False for generic TypedDict specializations

[semohr]

Bug report

Bug description:

It appears that typing.is_typeddict returns False when called on a specialized TypedDict that is used as a type parameter in a generic TypedDict. This behavior is not documented and seems unexpected.

from typing import is_typeddict, Generic, TypeVar, TypedDict

A = TypeVar("A", bound=TypedDict)

class Attributes(TypedDict):
    title: str

class Resource(TypedDict, Generic[A]):
    a: A 

print(is_typeddict(Resource[Attributes]))
# False (unexpected)

is_typeddict(Resource[Attributes]) should return True, since Resource[...] is still a TypedDict after specialization.

---

I reported this initially in python/typing#2280 where it was suggested I open an issues here.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

[JelleZijlstra]

The current behavior is consistent with other similar functions:

>>> class P[T](typing.Protocol): ...
... 
>>> typing.is_protocol(P)
True
>>> typing.is_protocol(P[int])
False
>>> import inspect
>>> inspect.isclass(list[int])
False
>>> inspect.isclass(list)
True
>>> inspect.isclass(list[int])
False

The rationale is that an object like list[int] is a generic alias (either types.GenericAlias or typing._GenericAlias), not a class itself. A generic alias like Resource[Attribute] in your example does not have the runtime attributes that a TypedDict class has, such as __required_keys__.

[sobolevn]

Use: print(is_typeddict(typ) or is_typeddict(get_origin(typ))) :)

[semohr]

The current behavior is consistent with other similar functions

The current behavior may be consistent with other similar functions, but consistency alone doesn’t justify keeping it. I believe this really should be reevaluated. All the examples you’ve given feel quite unintuitive to me, and definitely not what a typical Python end‑user would expect.

I understand the reasoning from an implementation standpoint, but from the perspective of a user who doesn’t want to dive into implementation details, this is a real headache.

[sobolevn]

@semohr but Resource[Attributes] is not a typed dict, it is a generic alias :)
These are two different things. For example, after running is_typeddict(typ) check, one might expect to have all the typed dict properties:

>>> from typing import TypedDict
>>> class Resource[T](TypedDict):
...     x: int

>>> Resource.__optional_keys__
frozenset()

>>> Resource[int].__optional_keys__
Traceback (most recent call last):
  File "<python-input-8>", line 1, in <module>
    Resouce[int].__optional_keys__
  File "/Users/sobolev/Desktop/cpython/Lib/typing.py", line 1314, in __getattr__
    raise AttributeError(attr)
AttributeError: __optional_keys__

But, they won't exist on a generic alias.
That's why we can't allow is_typeddict(Resource[int]) to return True. Because it is neither TypedDict nor looks like one :)

[semohr]

As I said, I totally get that from the implementation side.

For me this is not about the implementation tho but the typical usage. An average User would not expect there to be a difference between:

class Foo1(Gerneric[A], TypedDict):
    foo: A

class Foo2(TypedDict):
    foo: int


A = Foo1[int]
B = Foo2

Especially if A or B are exported from a third party module and the user does not look too closely how these are defined.