Anyway, why not just use field assignment in the declaration of TypedDict? ```python class MyDict(TypedDict): required_key: int optional_key: int = ... ``` It's way easier to implement (you don't have to evaluate annotations or use regex parsing) and IMO easier to read. It's also more consistent with how field requirement is handled in other standard data structures (`dataclass` and `NamedTuple`). 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. By the way, I think a simple placeholder is enough and there is no need for a thing like `dataclasses.field`. It's true that `dataclasses.field` provides a `metadata` parameter that could be useful, but PEP 593 has been released since, and it can be used for that.