![](https://secure.gravatar.com/avatar/c278b7144feb496c731ee0514355548c.jpg?s=120&d=mm&r=g)
On 2/27/21 9:57 AM, Daniel Moisset wrote:
class MyThing(TypedDict): Optional[opt1]: str # may not exist, but if exists, value is string opt2: Optional[str] # always exists, but may have null
value
These syntaxes would require Python grammar changes and it is not believed that marking TypedDict items as required or
potentially-missing
would meet the high bar required to make such grammar changes.
Also, “let’s just not put funny syntax before the colon.” [1]_
This is factually wrong for the second example; 'Optional[opt1]: str' is perfectly valid Python syntax right now.
Noted. Will update. On 2/28/21 9:26 AM, Paul Bryan wrote:
References to __required_keys__ and __optional_keys__ have now been merged into the 3.10 docs: https://github.com/python/cpython/pull/24668/files <https://github.com/python/cpython/pull/24668/files>
Cool.
As was discussed in another thread, could we deprecate __total__, ideally through this PEP?
I must have missed the other thread. By deprecate do you mean put through some kind of formal deprecation process such that accessing the attribute triggers warnings and later the attribute is removed outright? I am unfamiliar with how Python features are usually deprecated. I could potentially see deprecating `__total__` in this PEP. That flag is definitely misleading when there are keys of mixed totality, either via keys of mixed totality in a single TypedDict type, or through an inheritance chain of mixed totality.
Perhaps through text like:
The ``total`` parameter, combined with the use of ``Required[...]`` and ``Optional[...]`` manifests in the class ``__required_keys__`` and ``__optional_keys__`` attributes.
Best, -- David Foster | Seattle, WA, USA Contributor to TypedDict support for mypy