TypedDict in dynamic contexts

[jzazo]

Feature

I would like to be able to instantiate TypedDicts in dynamic contexts, for example:

tdict: dict[str, type] = {}
tdict["foo"] = int
tdict["bar"] = bool
booOutput = TypedDict("booOutput", tdict)

def boo(**kwargs) -> booOutput:
    return booOutput(**kwargs)

boo(foo=2, bar=False)

Pitch

I want to declare dynamic classes where I don't know statically what a method will return. But when I build the class I know the specific output types, and I would like to declare them so that I can rely on inspect.get_annotations or equivalent.

If TypedDict is not an option, is there a way that I can specify a return annotation dynamically when I create the class (a mapping return annotation)? This issue might be related. Thanks!

[erictraut]

This is also related to a recent discussion in the typing-sig. The consensus in that discussion was that TypedDict was designed for static type checking and that it is reasonable for static type checkers to emit errors if a TypedDict is constructed using dynamic arguments.

[hauntsaninja]

Not mentioned in the typing-sig thread, but NewType can also work for some of these use cases.

[felixvd]

This is also related to a recent discussion in the typing-sig.

[from the discussion]
I think I'd want to see some additional signal that your use case is something that is more broadly desirable before adding this support to pyright.

-Eric

Not sure if this is the right place, but I found this discussion trying to implement the use case @pbryan described in that thread: validating code with types derived from a schema. Packages like jsonschema-typed and jsonschema-gentypes also target this use case, and the commit above that is referencing this thread from a repo with >100 stars also says It would be convenient to generate types dynamically [in this manner], so I believe it is somewhat desirable.

I have not found a good workflow or workaround for this yet, but I agree that it would be very helpful.