![](https://secure.gravatar.com/avatar/833c1ef94aebf738851577a5cb0b71e7.jpg?s=120&d=mm&r=g)
On Wed, 2022-10-19 at 17:16 +0000, Jia Chen via Typing-sig wrote:
Is `TypedDict` strictly necessary in your use case? It seems to me that you can achieve the same goal by defining a plain dict where keys are field name strings and values are corresponding classes, e.g.
Yes, because unlike my overly simplistic example, real use cases derive TypedDict from live SQL schemas and server-generated OpenAPI documents to facilitate runtime type validation and value encoding/decoding during data interchange.
My understanding is that the entire motivation of `TypedDict` is to inform static type checkers what keys are in a dict and what are the corresponding value types. The bottom line here is that if you don't really know these info statically anyway, then going out of the way to construct a `TypedDict` feels a bit redundant.
While it may have been initially motivated by static type checking use cases, it's proven invaluable in dynamic typing cases. I sincerely hope it won't be exclusively for static type checking use cases.
If your proposal is to re-purpose the pre-existing `TypedDict` class in stdlib, to re-interpret it to be the "standard" class that represents the runtime structure for your own use case, then I do see some value of it. Although if we are proposing new changes to the Python stdlib, my expectation is that the bar would be a bit higher than "it's useful for me". Do you have more data points that suggest the feature is actually needed (or could potentially be widely useful) in practice?
TypedDict already works as advertised and as expected. The issue I raised pertained to how static type checkers were interpreting a particular case of constructing TypedDict, which demonstrably works at runtime. Jelle's suggested workaround will serve to suppress static type checking errors.