![](https://secure.gravatar.com/avatar/cc44e78b2855311d1735601449bfcbf2.jpg?s=120&d=mm&r=g)
Hi Paul, 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. ``` fields = ('a', 'b', 'c') TD = {field: str for field in fields} ``` There's no need to indirectly obtain the same info via `TypedDict.__annotations__`. Other goodies, like `__required_keys__`, can be obtained by creating your own wrapper class around dict with those additional fields. 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. 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? - Jia