PEP 728: TypedDict with Typed Extra Items

[PIG208 (Zixuan Li)]

Thank you for the feedback!

Re: the drawbacks of extra=, I think I should include a link to the reasoning for not favoring this syntax in a future revision.

There was a more recent discussion on the pros and cons of both approaches and I think it would be helpful to include this quote here:

@erictraut

other_keys versus __extra__

PEP 705 specifies an other_keys parameter whereas PEP 728 specifies a dundered __extra__ field. Neither of these formulations is ideal. I see disadvantages to both. Some of these disadvantages have not yet been discussed in either PEP, and I think it’s important for us to consider the full list of pros and cons before deciding.

Disadvantages of other_keys

• It’s not clear how this would work with inlined TypedDict type definitions (a feature that is not yet spec’ed but is in high demand).
• It’s not clear how to “spell” other_keys in a type synthesized within the type checker (e.g. using the process described in the PEP for the | “merge” operator). How should these types appear in error messages, hover text, etc.? What if two types differ only in their other_keys value, and the error indicates that one is not consistent with the other?
• The argument expression for other_keys is evaluated at runtime, which means that forward references will need to be quoted even when deferred annotation evaluation becomes the norm.
• It requires special-case handling in the type checker to verify that the expression is a valid static type expression and that Required and NotRequired are not used (although ReadOnly is permitted).

Disadvantages of __extra__

• It means that __extra__ cannot be used as a legitimate key name.
• It requires special-case handling in the type checker to disallow Required and NotRequired.

Given these tradeoffs, I slightly prefer __extra__, although I’m not crazy about either of them. I wonder if there are other options here that we haven’t yet considered.