Inconsistent behaviour when updating a typed dict with a "subset" typeddict

[Alexandre-SCHOEPP]

Context

I am handling configuration from various sources, including kwargs. To do this, I use the TypeDicts, and I got this unexpected error:

# minimum working example
from typing_extensions import TypedDict, NotRequired


class Config(TypedDict):
    a: str
    b: float


class UserOverride(TypedDict):
    a: NotRequired[str]


def get_default_config(user_override: UserOverride) -> Config:
    conf: Config = {
        "a": "hello world",
        "b": 1.
    }
    conf.update(user_override)
    conf.update(**user_override)  # Extra argument "a" for update of TypedDict [misc]
    return conf

The first update call does not raise any error, but the second, which is equivalent according to all python rules I known, does not function.

If mypy is enforcing a standard way of writing code (which may be the case), then the error message is horribly unhelpful, pointing me to go through my complex library to seek the various TypedDicts definitions and try and find an incompatibility that does not exist.

I also disagree with the assessment that one signature is better than the other. Pylance errors on the first update call, telling me that it does not match an overload (I am probably going to open an issue with them about it too).

System info

• OS: Windows 11
• Mypy: mypy 1.16.0 (compiled: yes)
• Python: 3.12.3

[sterliakov]

Note that .update(user_override) is also rejected under --strict:

https://mypy-play.net/?mypy=latest&python=3.12&flags=strict&gist=cebb6c33ceba44aa58e652e244247ff3

[Alexandre-SCHOEPP]

Note that .update(user_override) is also rejected under --strict:

https://mypy-play.net/?mypy=latest&python=3.12&flags=strict&gist=cebb6c33ceba44aa58e652e244247ff3

I don't understand this choice. Why shouldn't I update a subset of keys of my typeddict ?

[brianschubert]

Both calls are unsafe, since user_override could have arbitrary extra items that could conflict with Config. For example, {"b": "bad"} is a valid UserOverride. PEP 728 should make it possible to type this safely (if accepted).

[Alexandre-SCHOEPP]

Both calls are unsafe, since user_override could have arbitrary extra items that could conflict with Config. PEP 728 should make it possible to type this safely.

Can mypy not establish at runtime that the all keys of UserOverride (and by extent, user_override) are in Config ?
Wouldn't the only unsafe aspect be when I define both dicts ?

I understand that it would be unsafe, were UserOverride not to be a Typeddict

For example, {"b": "bad"} is a valid UserOverride.

Not according to mypy

[brianschubert]

Not according to mypy

Construction is a special-case outlined in the typing spec. I believe the idea was to help catch issues like typos in key names, though it has lead to some confusion due to its incongruence with the usual assignability rules. You can refer to the TypedDict Assignability section of the typing spec for the how TypedDict compatibility works in general.

[Alexandre-SCHOEPP]

Ok so it's not Mypy that is inconsistent, but rather Python 😫

[sterliakov]

Ok so it's not Mypy that is inconsistent, but rather Python 😫

Well, not that you should need typed dicts often. Such structural subtyping has problems that simply can't be resolved without knowledge about keys that aren't mentioned.

(I'll be mostly retelling the spec below)

The spec for TypedDict is at least sound. Consider the following chain of transformations:

class Full(TypedDict):
    a: str
    b: float

class Part(TypedDict):
    a: NotRequired[str]
    
class WrongPart(TypedDict):
    a: NotRequired[str]
    b: NotRequired[list[object]]


base: Full = {'a': '', 'b': 0}

part: WrongPart = {'b': []}
part_up: Part = part
base.update(part_up)

If both of them are allowed, you just ended up having a list under key b of type float. Not cool. So at least one of two last lines must be a type error. Naturally you want the upcast to succeed ("I only care about key a", it would be impossible to pass - even readonly - wider typeddicts to functions accepting narrow argument). So the lat line must be a type error, right?

Okay, there's a third option: say "who cares about type safety" (khm-khm TypeScript that just allows my example verbatim). It's definitely not something I expect from a type system of a mature and convenient language - such as python.