I think that Required, NotRequired and ReadOnly should be permitted here. Absent any mention of this, the typing spec could be interpreted as disallowing this. It's better to make it clear.

I presume that all inlined TypedDicts are implicitly "total" (i.e. all items are assumed to be Required unless explicitly NotRequired). This makes sense because it's consistent with precedent, but it would be good to spell it out in the spec.

I think it's also worth considering making all inlined TypedDicts implicitly "closed" (as defined in draft PEP 728). This would deviate from precedent, but I think one could make a good argument for why inlined TypedDicts should be closed.

I think that Required, NotRequired and ReadOnly should be permitted here. Absent any mention of this, the typing spec could be interpreted as disallowing this. It's better to make it clear.

I presume that all inlined TypedDicts are implicitly "total" (i.e. all items are assumed to be Required unless explicitly NotRequired). This makes sense because it's consistent with precedent, but it would be good to spell it out in the spec.

Updated.

I think it's also worth considering making all inlined TypedDicts implicitly "closed" (as defined in draft PEP 728). This would deviate from precedent, but I think one could make a good argument for why inlined TypedDicts should be closed.

Sounds reasonable. I have to say I'm still a bit confused with PEP 728 and closed=True. If we disallow subclassing inlined typed dictionaries, it means that every inlined typed dictionary is implicitly @final. What's the purpose of having closed=True then? I guess I should ask my question in the PEP 728 discussion thread instead.

Am I correct in assuming that there is no way for an inlined TypedDict to "extend" another (named) TypedDict? One could imagine supporting this using dictionary expansion syntax, but that adds complexity that may not be justifiable. It would also impose additional runtime requirements on TypedDict classes (they'd need to be iterable).

A good way to support inheritance could be to allow more than one argument to the subscript: TypedDict[Base, {"a": int}].

Did you consider reusing typing.Dict here? I can see some potential advantages. It's less verbose, doesn't have the baggage of builtins.dict, and the fact that this is a "typed" dict is already implicit given that it is imported from typing and involves type annotations.

Showing my TypeScript bias here 😅 but I'm wondering how sacrilegious it would be to avoid the subscription all together and simply use the dictionary itself?

def get_movie() -> {'name': str, 'year': int}:
    return {
        'name': 'Blade Runner',
        'year': 1982,
    }

This causes problems with the | operator at least. I've been thinking of writing up something like "Why can't we ...?" discussing why certain "obvious" ways to make typing more ergonomic may not work well in practice.

I think that such writeup would be very useful!

I added an extra section in the rejected ideas regarding the plain dict syntax.

On using typing.Dict, I kind of like the idea for the reasons you mentioned @erictraut. Dict[{...}] implicitly spells out as something like:

Dict[{...}]
|      |------> ...with some typed fields
|--> a dict... 

However, I still think this is debatable for a couple reasons:

• typing.Dict is currently marked as deprecated in the Python documentation (although not scheduled for removal). It might be confusing to undeprecate it.
• The same subscripting syntax — with the only difference being the number of type arguments — means two different things. Can be confusing as well.

I'll add an entry to the open issues so that we can further discuss this option.

No, this shouldn't be allowed by a static type checker. In this example, InlinedTD is a type alias.

If you change this to InlinedTD = TypedDict('InlinedTD', {'a': int}), then it should be allowed (as it is today) because InlinedTD is now a class, which can be used as a base class.

Yes, I think we should also discuss whether an inlined typed dictonary is a proper class or an instance of some new internal typing._InlinedTypedDict class. As specified currently in this PEP, an inlined typed dictionary is a also a class, with an empty string for __name__ (which isn't ideal to be fair). Initially, I wanted inlined typed dictionaries to be an instance of some _InlinedTypedDict class, but this complicates the runtime behavior. For example, should we allow accessing the introspection attributes?

InlinedTD = TypedDict[{'a': int}]
InlinedTD.__required_keys__
InlinedTD.__total__
# etc

I don't think we should support nested inlined TypedDict definitions as shown above. We should require that the type annotation for each item be a valid type expression, and a dictionary expression not enclosed by a TypedDict is an invalid type expression. The above example should therefore be changed to:

def get_movie() -> TypedDict[{"name": str, "year": int, "production": TypedDict[{"name": str, "location": str}]}]: ...

The grammar definition proposed above by Jelle already implies this, but the spec should make it clear that using nested dictionary expressions (like in the current code sample) is not allowed and should result in a type checker error.

I understand this might seem needlessly verbose, but if we allow dictionary expressions in type expressions outside of a TyepdDict type argument, it will create a cascade of exceptions and future composability issues. For example, we'd need to support raw dictionary expressions within Required, NotRequired, and ReadOnly.

Indeed using a nested inlined typed dictionary is more consistent! Changed.

(Using typing.Dict instead of TypedDict might help reducing verbosity here).

Pyright 1.1.387, which will be published in the next day, includes experimental support for the latest draft of this PEP.

Amazing, updated to reference the future release.

I wonder, is there a world in which eventually you could do something like:

Movie = Annotated[TypedDict[{'name': str, 'year': int}], Total(False)]

Or something like that for class args?

This would require:

• introducing a typing.Total class/function
• setting a precedent regarding the meaning of Annotated metadata, which is currently ignored by type checkers.

Hmm, I like the strict parametrization of TypedDict better, I feel like this would set an odd precedent and confuse some users.