Repository navigation
[match-case]: TypedDict interaction with mapping pattern #2185
Description
It seems match-cases mapping pattern is predestined to work well with TypedDict, but currently the spec is silent regarding TypedDict subtyping with respect to match case: https://typing.python.org/en/latest/spec/typeddict.html#subtyping-with-mapping
At the time of writing, not a single type checker (tested with mypy=1.19.1, pyright=1.1.408, ty=0.0.17, pyrefly=0.53.0 and zuban=0.6.0) can solve the following tests1, suggesting that some standardization / typing spec guidance may be useful.
from typing import TypedDict, assert_type, assert_never
class D(TypedDict):
name: str
value: int
def test_match_key(x: D | int) -> None:
match x:
case {"name": _}:
# runtime equivalent to (isinstance(x, Mapping) and "name" in x)
assert_type(x, D)
case _:
assert_type(x, int)
def test_match_key_and_value(x: D | int) -> None:
match x:
case {"name": str()}:
# runtime equivalent to (isinstance(x, Mapping)
# and "name" in x and isinstance(x["name"], str))
assert_type(x, D)
case _:
assert_type(x, int)
def test_non_match(x: D | int) -> None:
match x:
case {"value": str()}:
# runtime equivalent to (isinstance(x, Mapping)
# and "value" in x and isinstance(x["value"], str))
assert_never(x)
case _:
assert_type(x, D | int)Footnotes
-
technically, it is possible to make a shared subclass of
intandcollections.abc.Mapping, so theassert_typein thecase {...}are debatable, though the inference in thecase _branches should not be affected. ↩
Activity
[-][match-case]: `TypedDict` interaction with with mapping pattern[/-][+][match-case]: `TypedDict` interaction with mapping pattern[/+]JelleZijlstra commentedon Feb 20, 2026
I'm not sure we need to say anything in the spec here. Type checkers should reflect the runtime behavior; if they do not, that's an issue that can be handled by improving the type checker.