On Fri, 2021-02-12 at 14:23 -0800, Guido van Rossum wrote:
On Thu, Feb 11, 2021 at 10:54 PM Paul Bryan <pbryan@anode.ca> wrote:
On Thu, 2021-02-11 at 21:51 -0800, Guido van Rossum wrote:

[snip]

On Thu, Feb 11, 2021 at 9:13 PM Paul Bryan <pbryan@anode.ca> wrote:

4. When iterating through the TypedDict.__annotations__, will Required[...] be retained there, or would it need to be discovered through __required_keys__, or both?

Together, it seems the best would be to always suppress Required, and only store that info in __required_keys__. Unless I'm missing something subtle (somehow this all sounds like a series of trick questions :-).

+1. No trick questions. 😉

5. Could we do away (or at least deprecated) totality in TypedDict, and rely on this mechanism? (and/or possibly codify the use of __required_keys__?)


Do you mean the __total__ attribute? I guess that's already been superseded by __required_keys__ (and __optional_keys__ -- I don't recall why we need both).

Well, yes, __total__ as well as total=... initialization parameter. They must die!


Explain? The proposal here depends on total=False, and I wouldn't want to flip the default (it would break too much code).  I could do without the `__total__` class attribute though.

The quarrel I've had with total= is the issue of needing to explicitly create a subclass so as to scope which are required keys and which are not. If total=True is equivalent to wrapping every key specified in this particular TypedDict with Required[...] (with no implications to superclasses or subclasses), and only manifests in __required_keys__, (and not in __total__) then no objection.

 
Also, I don't think __required_keys__ or __optional_keys__ are documented, at least not in https://docs.python.org/3.10/library/typing.html. Is there any reason we can't codify them in 3.10 docs?

Nobody got to it yet? Maybe you'd be willing to submit a small PR for this?

I would be happy to.

Paul