This was suggested by @erictraut early in the GH PR discussion. I think one argument in favor of this is that closed=True is the behavior that most users want (see the numerous issues on mypy/pyright’s issue trackers about items() being typed as dict[str, object]). Also the way I see it, inline typed dictionaries are meant for one-off definitions (e.g. for a function parameter), and its scope is thus well known to the developer [1].
Considering the potential incompatibility with intersections, I’m also happy to switch back to closed=False to be the default, but @erictraut might have more arguments in favor of having closed-ness to be the default.
The dict_display production also includes dict_comprehension and ** unpacking, which isn’t allowed in the inline syntax.
Regarding having a way to specify totality/closed-ness/etc, I’ll refer to this comment: the inline syntax isn’t meant to support all features from the existing class/functional-based syntaxes. I’m also already not too satisfied with the current syntax (TypedDict[{...}]) and envy TypeScript’s capabilities.
On that note – before we go with this syntax – do you think there will be a future where new syntax could be used in type annotations (especially as in 3.14 they are now lazily evaluated)? A syntax with better ergonomics, that wouldn’t necessarily be valid Python syntax but would allow expressing typing concepts in a concise and (more) readable way?
If I use an inline TD for a parameter of a function I define, most of the time I expect no extra items to be present. ↩︎