Support inferring @final TypedDicts to be Mapping[str, Union | Of | Types] ?

[ringohoffman]

Posting this here at the suggestion of @erictraut since it seems like the OP didn't:

microsoft/pyright#3526

According to Eric:

Currently, the details of TypedDict are provided by the _TypedDict class definition in the typeshed typing.pyi, which indicates that all TypedDict instances derive from Mapping[str, object].

Which results in the current behavior:

from typing import TypedDict, final


@final
class MyTypedDictOfStr(TypedDict):
    str_field: str
    other_str_field: str


my_dict_of_str: MyTypedDictOfStr = {
    "str_field": "",
    "other_str_field": "",
}

for value in my_dict_of_str.values():
    reveal_type(value)  # object

[erictraut]

Thinking about this more, I don't know if it makes sense to ascribe any meaning to @final for a TypedDict. A TypedDict is a structural type (similar to a protocol), not a nominal type. Other types do not need to derive from a TypedDict to be type compatible with it. The @final decorator means "this class cannot be subclassed", but subclassability is not a factor when determining whether a given type is compatible with a structural type.

[ringohoffman]

Thinking about this more, I don't know if it makes sense to ascribe any meaning to @final for a TypedDict. A TypedDict is a structural type (similar to a protocol), not a nominal type. Other types do not need to derive from a TypedDict to be type compatible with it. The @final decorator means "this class cannot be subclassed", but subclassability is not a factor when determining whether a given type is compatible with a structural type.

Then instead of using @final, would it make sense to infer Mapping[str, Union | Of | Types] when TypedDict(total=True)? Since does this not statically enforce that no keys with unknown values will be added?

[erictraut]

I don't think that would make sense. TypedDict(total=True) does not indicate whether additional keys (beyond those that are declared) can be present; it simply means that ll declared entries should be marked Required.

As for whether a TypedDict should be type compatible with Mapping[str, <union of value types>], I think there are two defensible answers:

1. A TypedDict is never compatible with Mapping[str, <union of value types>]. This is the behavior enforced today by all Python type checkers (to my knowledge). This is defensible because it's not strictly type safe to make this assumption because TypedDicts are structural types. A type that complies with the TypedDict's structural definition does not necessarily comply with the requirements of Mapping[str, <union of value types>] because additional (unspecified) keys could be present.
2. A TypedDict is always compatible with Mapping[str, <union of value types>]. This is the behavior that TypeScript adopts for its equivalent of TypedDict. This isn't strictly type safe, but the TypeScript team decided to make this tradeoff for practical reasons. With my many years of writing TypeScript code, I can't remember ever encountering a real bug that resulted from this "hole" in the type system. That means this was probably a good tradeoff — one that we may want to consider for Python typing as well.

Here's a snippet of TypeScript that demonstrates this:

type AB = {
  a: string;
  b: number;
};

type A = {
  a: string;
};

type AnyKeysStringOrNumber = {
  [key: string]: string | number;
};

type AnyKeysStringOnly = {
  [key: string]: string;
};

let ab: AB = { a: "hi", b: 0 };

const v1: AnyKeysStringOrNumber = ab; // No type error
const v2: AnyKeysStringOnly = ab; // Type error: "b" is not compatible with string

const v3: A = ab // No type error
const v4: A = v1 // Type error - missing "a"

[david-flok]

It appears that there is a demand for 'closed' TypedDict types that behave like the present TypedDicts but guarantee that no additional keys can be present and thus unify with Mapping[str, <union of value types>]. This need is most felt when wanting to use TypedDicts for value types dependent on keys to, e.g., enforce a schema and then wanting to have a static check that the schema is JSON serializable.

[JelleZijlstra]

https://peps.python.org/pep-0728/ provides this.