Anyway, why not just use field assignment in the declaration of TypedDict?
```python class MyDict(TypedDict): required_key: int optional_key: int = ... ``` It's not clear to me how field assignment would convey "this item is
On 2/20/21 10:40 AM, Joseph Perez wrote: potentially-missing". If anything it says "there's something here but I'm not specifying what".
It's way easier to implement (you don't have to evaluate annotations or use regex parsing) and IMO easier to read.
None of the prior proposals require regex parsing or runtime evaluation of annotations.
It's also more consistent with how field requirement is handled in other standard data structures (`dataclass` and `NamedTuple`).
NamedTuple's assignment syntax is used for specifying *default values*, not potentially-missing items.
I think `Ellipsis`/`...` is a perfect placeholder for this use, but it can be debated.
`total` would become quite useless with this proposal (just a shortcut to make all keys optional), but I don't think it would be an issue because again, things are more consistent this way. IMO, `total` could even be deprecated (but kept for backward compatibility, of course).
To make it compatible with the assignment-based syntax, a parameter, let's name it `optional_keys`, could be added and used this way: ```python MyDict = TypedDict("MyDict", {"required_key": int, "optional_key": int}, optional_keys=["optional_key"]) ``` Yes, the key name is repeated, but I don't think assignment-based syntax is used a lot, so it should be ok; I might be wrong.
The assignment-based syntax was intentionally made less-capable that the class-based syntax to encourage folks to migrate to the class-based syntax. There's no reason to update it. -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy