Various `dict` forms and subtypes not accepted as `TypedDict`

[KotlinIsland]

from typing import TypedDict
from collections import defaultdict, OrderedDict, UserDict
class Movie(TypedDict):
    name: str
    year: int

movie_literal: Movie = {"name": "asdf", "year": 2}
movie_dict_kw: Movie = dict(name="asdf", year=2)
movie_dict_literal: Movie = dict({"name":"asdf", "year":2})  # expression has type "Dict[str, object]"
movie_defaultdict_kw: Movie = defaultdict(name="asdf", year=2)  # expression has type "defaultdict[<nothing>, object]"
movie_defaultdict_literal: Movie = defaultdict(str, {"name": "asdf", "year": 2})  # expression has type "defaultdict[str, object]"
movie_defaultdict_dict_kw: Movie = defaultdict(str, dict(name="asdf", year=2))  # expression has type "defaultdict[str, object]"
movie_userdict_literal: Movie = UserDict({"name": "asdf", "year": 2})  # expression has type "UserDict[str, object]"
movie_ordereddict_literal: Movie = OrderedDict({"name": "asdf", "year": 2})  # expression has type "OrderedDict[str, object]"

[erictraut]

Mypy is correct here. All of these expressions (other than the first) are not valid subtypes of Movie.

[KotlinIsland]

Why? They are all dicts that have the right key type/value type.

I had a look at the TypedDict pep and it didn't mention anything about excluding dict subtypes.

also:

movie_dict_kw: Movie = dict(name="asdf", year=2)   # accepted 
movie_dict_literal: Movie = dict({"name":"asdf", "year":2})  # not accepted

This one seems blatantly inconsistent.

[hauntsaninja]

The issue is that type checkers don't know what constructors do:

class MyLovelyDict(dict):
    def __init__(self, d: dict) -> None:
        throw_away(d)
        super().__init__({"not": "what you thought"})

Type checkers only really look at things in terms of types, not values. So:

dict({"name": "asdf", "year": 2})

looks the same as:

_x: dict[str, object] = ...
dict(_x)

[ajoino]

Disclaimer: I don't understand exactly how the Python typing system and mypy works under the hood. Please educate me if you have the time :)

Why was this issue closed? I understand that the TypedDict protocol cannot support all possible user-defined mappings, but it seems weird to me that OrderedDict and defaultdict are unsupported. If type checkers only look at values, how is TypedDict supported in the first place, since it's defined by the values of the keys? As @KotlinIsland is saying, this behaviour feels inconsistent from a user perspective.

[KotlinIsland]

@ajoino

I don't understand exactly how the Python typing system and mypy works under the hood.

Not many people do unfortunately.

What's happening here:

dict(a=1)

Is that the keyword signature is handled intrinsically(special cased in the mypy internals, and not part of the normal type system) and validated correctly, but:

reveal_type(dict({'a': 1}) # dict[str, int]

This signature is annotated as __map: SupportsKeysAndGetItem[_KT, _VT] which is unrelated to the TypedDict.

There's no technical reason that this scenario couldn't also be made intrinsic, but it's more of a "who asked" kind of situation.

[KotlinIsland]

Consider this, from a type system perspective this should be consistent, but it's not because of the intrinsic behaviour of dict

from typing import TypedDict, _KT, _VT

class T(TypedDict):
    a: int

class MyDict(dict[_KT, _VT]):
    ...
        
t1: T = dict(a=1) # no error
t2: T = MyDict(a=1) # error

[jhance]

How do you expect that to be consistent when mypy has no idea what the constructor of MyDict does?

It seems plausible that OrderedDict could make sense - out of the use cases that one is the only one that seems useful to me (what is the purpose of a default typed dict and how is it going to be different than a non-total typed dict?). And since its a builtin we know it doesn't do something silly in the constructor.

[KotlinIsland]

How do you expect that to be consistent

I don't, I was just demonstrating something intrinsic.

what is the purpose of a default typed dict and how is it going to be different than a non-total typed dict

defaultdict is a subtype of dict, so it should work the same. I can't think up a use case on the spot, but that doesn't mean there isn't one.