On 2/20/21 12:44 PM, Joseph Perez wrote:
None of the prior proposals require regex parsing or runtime evaluation of annotations.
Without regex parsing or runtime evaluation of annotations, how can `TypedDict` metaclass know that a field is required or not? Especially when using `from __future__ import annotations` (aka. PEP 563)?
`Required[T]` can evaluate to a box of type Required with parameter T, which the TypedDict __new__ can inspect. It can be implemented in a straightforward fashion.
Using `get_type_hints` is not a solution, because it prevents declaring recursive `TypedDict`. `dataclass` decorator has the same issue, and it solves it using regex parsing. IMO runtime evaluation of annotation are better here (in the typing module, private API like `_eval_type` is available), but I don't see an other way of doing this.
NamedTuple's assignment syntax is used for specifying default values, not potentially-missing items.
If you understand `...` in `TypedDict` context as a kind of javascript `undefined`, comparison with `NamedTuple` can be done.
It's not clear to me how field assignment would convey "this item is potentially-missing". If anything it says "there's something here but I'm not specifying what".
Or maybe it can says "the value of this key can be undefined".
I'm not a fan of this syntax. -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy