I hope the purpose of TypedDict is not to exclusively support *static* type checking. It's proven to be very useful in dynamic typing cases as well.
Overly-simplistic sample code for demonstration of comprehension:
>>> fields = ("a", "b", "c")
>>> TD = TypedDict("TD", {field: str for field in fields}
>>> TD.__annotations__
{'a': <class 'str'>, 'b': <class 'str'>, 'c': <class 'str'>}
>>> TD.__required_keys__
frozenset({'a', 'c', 'b'})
Real world use cases of dynamically-generated TypedDict:
- deriving a typed dictionary from a SQL table schema to support dynamic data validation and interchange
- deriving a typed dictionary from machine-readable API (e.g. OpenAPI) document to support dynamic data validation and interchange
As demonstrated above, this works very well at runtime, and I can't think of a reason to prohibit the construction of a TypedDict from a comprehension. Static typing tools do complain (as well as IDEs that utilize them) and this seems spurious in light of evidence that it is both useful and fully functional.
On Wed, 2022-10-19 at 16:11 +0000, Eric Traut wrote:
Could you provide a more complete (self-contained) code sample? When you say "construct a TypedDict", do you mean "define a new TypedDict class"? Or are you talking about calling the constructor for an existing TypedDict class? It looks like you mean the former, but it's not clear from your terminology.
The purpose of TypedDict is to support static type checking. If you don't care about static type checking, you can simply use `dict`. If you do care about static type checking, then a TypedDict that is the equivalent of dict[Any, Any] seem to be of no value, so I'm not sure why one would want to define a TypedDict class in that manner. Perhaps you could explain your use case in more detail?
-Eric
--
Eric Traut
Contributor to pyright & pylance
Microsoft
_______________________________________________