Generic TypedDict types are not supported in response validation decorators

[semohr]

When using TypedDict with Generic / TypeVar, the resulting type cannot be used with validation decorators such as @validate_response.

Example

I'm trying to create a simple json:api like schema and was wondering if it is supported.

A = TypeVar("A")

class Resource(TypedDict, Generic[A]):
    type: str
    id: str
    attributes: A 

class ItemAttributes(TypedDict, total=False):
    title: str

# Error
@app.get("/items", methods=["GET"])
@validate_response(Resource[ItemAttributes])
async def get_items() -> Resource[ItemAttributes]:
   ...

# Works
@app.get("/items", methods=["GET"])
async def get_items() -> Resource[ItemAttributes]:
   ...

I would have expected this works as msgspec does not seems to have issues here.

msgspec.json.schema(Resource[ItemAttributes]) # works
# Same for encode/decode

Best, S

---

 Traceback (most recent call last):
   File "/venv/lib/python3.12/site-packages/quart/app.py", line 1500, in full_dispatch_request
     result = await self.dispatch_request(request_context)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart/app.py", line 1597, in dispatch_request
     return await self.ensure_async(handler)(**request_.view_args)  # type: ignore[return-value]
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart_schema/extension.py", line 321, in openapi
     schema = self.openapi_provider.schema()
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart_schema/openapi.py", line 62, in schema
     path_objects, path_components = self.build_paths(rule)
                                     ^^^^^^^^^^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart_schema/openapi.py", line 178, in build_paths
     response_object, response_components = self.build_response_object(
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart_schema/openapi.py", line 341, in build_response_object
     schema = model_schema(
              ^^^^^^^^^^^^^
   File "/venv/lib/python3.12/site-packages/quart_schema/conversion.py", line 217, in model_schema
     raise TypeError(f"Cannot create schema for {model_class}")

[semohr]

I took a quick look into the root cause, and I think I have an idea why this is happening:

The is_typeddict function used in _use_msgspec and _use_pydantic does not correctly evaluate to True for TypedDicts that inherit from generics. This appears to remain true even when the generic parameters are fully resolved (e.g. Resource[ItemAttributes]).

One possible workaround would be to relax the check for TypedDict detection, for example by inspecting the origin and checking something along the lines of:

dict in get_origin(model_class).__mro__

I’m not fully familiar with the surrounding codebase, so I’m not sure if this is the best or safest fix. Let me know what you think, happy to implement a proper fix if you’d like, or leave it to someone more familiar with the codebase.

[pgjones]

I think there is something else at play here as the following works for me in Python 3.12,

from typing import Generic, TypeVar, TypedDict, is_typeddict

A = TypeVar("A")

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

assert is_typeddict(B)

[semohr]

Does not work for me and is consistently reproducable. I think it only happens when a specialization is applied.

B[specialization]

I opened an issue in the typing repo as this seems weird to me in gerneral.

python/typing#2270

[pgjones]

Weird, I can confirm

from typing import is_typeddict, TypedDict

class C(TypedDict, total=False):
    title: str

class B[T](TypedDict):
    a: T

assert is_typeddict(B[C])
assert is_typeddict(B[int])

Reproduces for me. I think the typing issue is the one to check

[semohr]

As an update regarding this: This all seems to be expected behavior. As B[int] or B[C] are not "real" TypedDicts they are generic aliases. While a bit counterintuitive it does make sense when looking at it from the python internal perspective.

I proposed a fix in #120 which uses get_origin to resolve generic aliases (and introduces some tests for them). Feel free to have a look.