Experimental: allow inline/anonymous TypedDicts

[ilevkivskyi]

Fixes https://github.com/python/mypy/issues/9884

I was always a bit skeptical about this thing, since it feels more like TypeScript than Python, but it is second most upvoted issue. Also (this specific) implementation is like 60 lines of code plus tests, so why not.

I know there is no PEP etc., but IMO this syntax is obvious and it just works. cc @JukkaL

[github-actions[bot]]

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]

[github-actions[bot]]

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]

[bzoracler]

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?

[ilevkivskyi]

@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).

[github-actions[bot]]

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]

[ilevkivskyi]

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

[sobolevn]

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.