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 typeintersection instead of a union,

classA: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
• inlineTypedDict 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 banninglist[int] on old Python versions).

Diff frommypy_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 thatTypedDict[{"a": int}] is better than{"a: int}, for exampleTypedDict[{"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 rejecteddefadd_key(obj:_TD)->TypedDict[{*_TD,*{"b":int}}]:obj["b"]=0returnobj

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 thetyping /typing_extensions module, while this one does not require any changes.