Typing specification changes

The inlined typed dictionary adds a new kind of type expression. As such, the type_expression production will be updated to include the inlined syntax:

new-type_expression ::=  type_expression
                         | <TypedDict> '[' '{' (string: ':' annotation_expression ',')* '}' ']'
                               (where string is any string literal)

Runtime behavior

Although TypedDict is commonly referred as a class, it is implemented as a function at runtime. To be made subscriptable, it will be changed to be a class.

Creating an inlined typed dictionary results in a new class, so T1 and T2 are of the same type:

from typing import TypedDict

T1 = TypedDict('T1', {'a': int})
T2 = TypedDict[{'a': int}]

As inlined typed dictionaries are are meant to be anonymous, their __name__ attribute will be set to an empty string.

Runtime implementation

A draft implementation is available here.

Using the functional syntax in annotations

The alternative functional syntax could be used as an annotation directly:

def get_movie() -> TypedDict('Movie', {'title': str}): ...

However, call expressions are currently unsupported in such a context for various reasons (expensive to process, evaluating them is not standardized).

This would also require a name which is sometimes not relevant.

Using dict with a single type argument

We could reuse dict with a single type argument to express the same concept:

def get_movie() -> dict[{'title': str}]: ...

While this would avoid having to import TypedDict from typing, this solution has several downsides:

• For type checkers, dict is a regular class with two type variables. Allowing dict to be parametrized with a single type argument would require special casing from type checkers, as there is no way to express parametrization overloads. On the other hand, TypedDict is already a special form.
• If future work extends what inlined typed dictionaries can do, we don’t have to worry about impact of sharing the symbol with dict.

Using a simple dictionary

Instead of subscripting the TypedDict class, a plain dictionary could be used as an annotation:

def get_movie() -> {'title': str}: ...

However, PEP 584 added union operators on dictionaries and PEP 604 introduced union types. Both features make use of the bitwise or (|) operator, making the following use cases incompatible, especially for runtime introspection:

# Dictionaries are merged:
def fn() -> {'a': int} | {'b': str}: ...

# Raises a type error at runtime:
def fn() -> {'a': int} | int: ...

Subclassing an inlined typed dictionary

Should we allow the following?:

from typing import TypedDict

InlinedTD = TypedDict[{'a': int}]


class SubTD(InlinedTD):
    pass

What about defining an inlined typed dictionay extending another typed dictionary?:

InlinedBase = TypedDict[{'a': int}]

Inlined = TypedDict[InlinedBase, {'b': int}]

Using typing.Dict with a single argument

While using dict isn’t ideal, we could make use of typing.Dict with a single argument:

def get_movie() -> Dict[{'title': str}]: ...

It is less verbose, doesn’t have the baggage of dict, and is already defined as some kind of special form.

However, it is currently marked as deprecated (although not scheduled for removal), so it might be confusing to undeprecate it.

This would also set a precedent on typing constructs being parametrizable with a different number of type arguments.

Should inlined typed dictionaries be proper classes?

The PEP currently defines inlined typed dictionaries as type objects, to be in line with the existing syntaxes. To work around the fact that they don’t have a name, their __name__ attribute is set to an empty string.

This is somewhat arbitrary, and an alternative name could be used as well (e.g. '<TypedDict>').

Alternatively, inlined typed dictionaries could be defined as instances of a new (internal) typing class, e.g. typing._InlinedTypedDict. While this solves the naming issue, it requires extra logic in the runtime implementation to provide the introspection attributes (such as __total__), and tools relying on runtime introspection would have to add proper support for this new type.

Inlined typed dictionaries and extra items

PEP 728 introduces the concept of closed type dictionaries. Inlined typed dictionaries should probably be implicitly closed, but it may be better to wait for PEP 728 to be accepted first.