If you agree, I’ll add you as a sponsor in the next update.
I would be happy to!
From my past experience, it is a good idea to limit the scope of this feature to a bare minimum. We can always add something when needed (like & syntax / inheritance / etc)
I like this proposal. Tbh I’m not a huge fan of TypedDict in general, but given that we seem to be stuck with it, this would make declaring simple TypedDicts much more ergonomic.
My 2c on the open issues section:
Subclassing an inlined typed dictionary: I don’t think either of these should be allowed. They don’t strike me as adding a huge amount of value in exchange for the additional complexity.
Using typing.Dict with a single argument: I prefer the existing proposal’s use of TypedDict, which makes it obvious that the new syntax constructs a TypedDict under the hood.
Should inlined typed dictionaries be proper classes?: No strong opinion on this. My default opinion is that whatever is simplest to implement that doesn’t cause obvious problems is the way to go for a first pass
Inlined typed dictionaries and extra items: I think it would be useful to have a line in the PEP stating that if PEP 728 is accepted, inlined typed dictionaries should be closed by default. That shows that interactions with other features have been thought through.
as an expressive way to declare some keyword args are (truly) not required (as opposed to the alternatives today)
def foo(*, name: str, year : int | None = None): ...
# or, maybe if `None` has meaning in the API
def foo(*, name: str, year : int | OMITTED_T = OMITTED): ...
# or the increasingly-verbose
@overload
def foo(*, name: str): ...
@overload
def foo(*, name: str, year : int): ...
def foo(*, name: str, **kwargs): ...
Yeah, sorry, typo (I always forget the Unpack bit, I’ll edit).
This is exactly what I was suggesting be pointed out in the proposal. That it is expected for it to “just work” in this manner. (Otherwise without an example, all I see is return-type examples, so it could be argued its ambiguous)
| <Unpack> '[' name ']'
(where name refers to an in-scope TypedDict;
valid only in **kwargs annotations)
Alternatively, it could be updated to state to an in-scope or inlined TypedDict. Let me know on the PR, I can add this edit (I also added an example of an inlined typed dictionary used as a parameter type).