While I like the elegance of the bare literal dict, the problem is that it doesn't compose well with union expressions in type annotation contexts.

Without a __future__.annotations guard, a union of two bare literal dicts in a runtime type annotation context will result in what looks like a type intersection instead of a union,

class A:
    a: {"int": int} | {"str": str}

>>> A.__annotations__
{'a': {'int': <class 'int'>, 'str': <class 'str'>}}

and a union with most other objects would result in a runtime error (e.g. {"str": str} | list[int]).

Maybe (before a PEP etc is proposed for the actual syntax), unions should be banned from being composed with bare literal dicts?

@bzoracler Although a valid concern, this is really a corner case. I mean all four things need to happen:

• __future__.annotations are not used
• inline TypedDict is used
• TypedDict appears in a union
• the user is interested in runtime type-checking

If I would guess, this will probably affect 0.01% of users. I don't want to force the rest 99.99% of users to see some ugly/non-intuitive syntax because of this. We already made similar mistakes in the past (like banning list[int] on old Python versions).

Diff from mypy_primer, showing the effect of this PR on open source code:

steam.py (https://github.com/Gobot1234/steam.py)
- steam/http.py:901: error: Invalid type comment or annotation  [valid-type]
+ steam/http.py:901: error: Inline TypedDict is experimental, must be enabled with --enable-incomplete-feature=InlineTypedDict  [misc]

@JukkaL I put this behind a flag, if there are no more suggestions I will be merging this soon.

I presented this topic to Guido, @erictraut, @JelleZijlstra, @JukkaL and others around a year ago.

As far as I remember we decided not to go for this feature. Several take-aways from this meeting:

1. I think that all agreed that TypedDict[{"a": int}] is better than {"a: int}, for example TypedDict[{"a: int"}] | None will work when {"a": int} | None - won't.
2. The most problematic part (which really killed the proposal) was the semantics for update / inheritance for inline typed dict. Let's say that you have a function like:

_TD: TypeAlias = TypedDict[{"a": int}]

# Syntax was not decided and the whole idea was rejected
def add_key(obj: _TD) -> TypedDict[{*_TD, *{"b": int}}]:
    obj["b"] = 0
    return obj

At the time I felt like inline typed dicts are not useful enough with the "extension" / "update" / "inheritance" syntax. But, now I think that it might be a good idea to start small.

3. The syntax above in my example would require a PR / spec for the typing / typing_extensions module, while this one does not require any changes.