(Speaking for myself, not the SC, although these questions did come out of discussions with the rest of the SC).
I think the use-case for TypedDict for **kwargs is sensible, and a logical extension of both PEP 646 and PEP 589, but I have strong reservations about the syntactic change. Specifically, the PEP introduces a new meaning of **
in an expression (but only in one specific context), something that’s in line with the use of **
for parameter lists but very different from **
elsewhere in expressions. So I have a few pointed questions:
- How much does using
**
actually win here? The alternative is to useUnpack
, which doesn’t seem that bad, especially since it’s an established annotation. Is the use ofUnpack
really confusing enough, or common enough, or error-prone enough to warrant special syntax? Is the use of**
really obvious enough, and discoverable enough, to be less confusing or less error-prone? - How bad would be it be to invalidate type annotations on
**kwargs
that aren’tUnpack
? Do people actually want the current behaviour of annotating**kwargs
? Regardless of whether they do, is the current behaviour actually desirable? - If the current behaviour isn’t desirable, how bad would it be to transition to using
TypedDict
semantics by default on**kwargs
annotations? How many annotations of**kwargs
using the old semantics are in fact correct, rather than misunderstandings or overly broad annotations likeAny
? - I feel like at some point in the journey to type-annotate all Python code we will end up discovering mistakes of the past or better ways of doing things, so having transition processes is probably a good idea. Something similar in concept, if not design, as
__future__
imports. Considering the simplicity of theUnpack
alternative to the new syntax, and assuming a transition is warranted, would this not be a good testing ground for such a process?
Just so it’s clear, the SC hasn’t decided yet on the PEP, one way or another, but I would like some clarity on the questions above to help make the decision.