`TypedDict` with `total=False` and `NotRequired` still throws an error when instantiated without all fields

[jonded94]

Bug Report

In this example, all fields (b and a) are not required, the field a (which is the problem here) is not required by both wrapping it in NotRequired and having its class be annotated with total=False:

from typing import TypedDict, NotRequired

class Bar(TypedDict, total=False):
    b: str

class Foo(Bar, TypedDict, total=False):
    a: NotRequired[int]

g = Bar()
f = Foo(**g)

All other type checkers which I know of don't throw a warning here:

$ ty check mypytest.py 
WARN ty is pre-release software and not ready for production use. Expect to encounter bugs, missing features, and fatal errors.
Checking ------------------------------------------------------------ 1/1 files                                                                                                                                                                                                                                     All checks passed!                                 
$ pyrefly check mypytest.py 
 INFO 0 errors
$ pyright mypytest.py
0 errors, 0 warnings, 0 informations

But mypy throws this:

$  mypy --strict mypytest.py
mypytest.py:10: error: Non-required key "a" not explicitly found in any ** item  [typeddict-item]
Found 1 error in 1 file (checked 1 source file)

Why is it a problem that a "Non-required" key wasn't found? What is this error message about?

For reference, setting total=True and removing the NotRequired wrapper will lead to all of these type checkers throwing an error:

$ pyright mypytest.py 
WARNING: there is a new pyright version available (v1.1.398 -> v1.1.405).
Please install the new version or set PYRIGHT_PYTHON_FORCE_VERSION to `latest`

error: No overloads for "__init__" match the provided arguments
    Argument types: (**Bar) (reportCallIssue)
1 error, 0 warnings, 0 information
$ pyrefly check mypytest.py
ERROR Missing argument `a` in function `Foo.__init__` [missing-argument]
  --> mypytest.py:10:8
   |
10 | f = Foo(**g)
   |        ^^^^^
   |
 INFO 1 error
$  ty check mypytest.py
WARN ty is pre-release software and not ready for production use. Expect to encounter bugs, missing features, and fatal errors.
Checking ------------------------------------------------------------ 1/1 files                                                                                                                                                                                                                                     error[missing-typed-dict-key]: Missing required key 'a' in TypedDict `Foo` constructor                                                                                                                                                                                                                              
  --> mypytest.py:10:5
   |
 9 | g = Bar()
10 | f = Foo(**g)
   |     ^^^
   |
info: rule `missing-typed-dict-key` is enabled by default

Found 1 diagnostic

Even mypy throws an error here, but interestingly, it's a different one:

$ mypy --strict mypytest.py
mypytest.py:10: error: Missing key "a" for TypedDict "Foo"  [typeddict-item]
Found 1 error in 1 file (checked 1 source file)

To Reproduce

mypy --strict mypytest.py

Expected Behavior

Not throw an warning/error.

Actual Behavior

mypytest.py:10: error: Non-required key "a" not explicitly found in any ** item  [typeddict-item]
Found 1 error in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 1.18.2
• Mypy command-line flags: --strict
• Python version used: 3.12.9

[sterliakov]

This code is actually unsafe, but I agree the error message should be improved (maybe emit a note?).

Here's an extension of your example:

from typing import TypedDict, NotRequired

class Bar(TypedDict, total=False):
    b: str

class FullBar(TypedDict, total=False):
    a: str
    b: str

class Foo(Bar, TypedDict, total=False):
    a: NotRequired[int]

def check(g: Bar) -> None:
    f = Foo(**g)
    reveal_type(f.get('a'))

x: FullBar = {"a": ""}
check(x)

The revealed type must be int | None, and yet at runtime it will be builtins.str. So mypy is correct reporting this, and maybe you should report this as a false negative to other type checkers.

[jonded94]

Thank you very much @sterliakov for the very quick answer!

I get that mypys behaviour indeed is reasonable from the example you constructed. Although I slightly get the gut feeling when reading this example that check shouldn't be covariant in g, i.e. not allow FullBar as an input type, such that the unsafeness in the function itself couldn't occur, but this of course is unrealistic and only has to do with how g is used in this function.

I'm still a bit helpless then how to actually solve the real-world problem that we have.
We have a bunch of functions that are typehinted with Unpack over a couple of TypedDicts. This is extremely helpful since we pass these TypedDicts through several call layers and repeating all kwargs or coming up with a bespoke config object or so would be too tedious and break a few workflows.

Let me construct this example which more closely relates to our problem:

class Bar(TypedDict, total=False):   # corresponds to `kwargs` of some `bar` func
  bar1: int
  bar2: int
  bar3: int

class Baz(TypedDict, total=False):  # corresponds to `kwargs` of some `baz` func
  baz1: int
  baz2: int
  baz3: int

class Foo(Bar, Baz, TypedDict,total=False):  # corresponds to a higher-level wrapper function `foo` that in turn calls `bar` and `baz`
  foo1: int
  foo2: int

We now often have the use case that out of all these mentioned fields, we only want to populate a small subset at several places in the code base, and Bar and Baz are initialized some distance away from Foo:

def extract_subset_from_dict[T: Mapping[str, Any]](input_dict: T, subset_type: type[T]) -> T:
    """
    Extract a subset of a dictionary into an object of a specified type.
    """
    return subset_type(**{k: v for k, v in input_dict.items() if k in subset_type.__annotations__})

def bar(**kwargs: Unpack[Bar]) -> None: ...
def baz(**kwargs: Unpack[Baz]) -> None: ...
def foo(**kwargs: Unpack[Foo]) -> None: 
  bar(**extract_subset_from_dict(kwargs, Bar))
  baz(**extract_subset_from_dict(kwargs, Baz))

bar_example = Bar(bar3=3)
baz_example = Baz(baz1=2)
foo_example = Foo(**bar_example, **baz_example, foo2=3)

foo(**foo_example)

This pattern is really nice for our needs, and especially doesn't require any maintainance when an additional optional field was added to either Bar, Baz or Foo.

With mypy however, this pattern doesn't work, even though one definitely could in principle statically check that no unsafness is happening here. There are two solutions:

• Put a # type: ignore[typeddict-item] comment at the line where foo_example is constructed
• "Needlessly" set all fields of Foo where foo_example is constructed, even though foo1 for example isn't needed
  • Setting foo1 to a value could even hurt, and maybe some functionality relies on this not being set at all

My question here is:
Given a valid and already constructed Bar and Baz, is there any way to construct a Foo out of that, without having to set all fields that Foo defines ontop?

[sterliakov]

Given a valid and already constructed Bar and Baz, is there any way to construct a Foo out of that, without having to set all fields that Foo defines ontop?

Probably not. There's PEP 728 (not yet implemented in mypy) that might help. I believe making Bar and Baz closed (which seems to fit your explanation) would make such a conversion safe.

[jonded94]

Okay, thanks! Just for reference, the only way I could make it work is through yet another Unpack factory method, but this does seem a bit silly:

def build_foo(**kwargs: Unpack[Foo]) -> Foo:
  return Foo(**kwargs)


bar_example = Bar(bar3=3)
baz_example = Baz(baz1=2)
foo_example: Foo = build_foo(**bar_example, **baz_example, foo2=3)

Will close this issue, as this should be solved with closed=True in Python 3.15, as you said :)