emit diagnostic on access of `NotRequired` typeddict key

[GniLudio]

Summary

Even though the feature overview and the support TypedDict issues show NotRequired as supported, it seems to be not working correctly.

In the following example MyDict.foo must not necessarily exist, but ty always assumes it's existence.

Example

from typing import TypedDict, NotRequired

class MyDict(TypedDict):
    foo: NotRequired[str]

my_dict: MyDict = {}

# assignment to a string variable doesn't give a warning
my_string: str = my_dict["foo"]

# assignment to a string parameter doesn't give a warning
def print_string(s: str) -> None:
    print(s)
print_string(my_dict["foo"])

Playground

Version

ty 0.0.17 (8cec857 2026-02-13)

[carljm]

Yes, we should add this diagnostic - thanks for the report. (Only pyright seems to emit a diagnostic in these cases; mypy and pyrefly do not. So there doesn't seem to be a consistent interpretation of type checkers here. But clearly soundness requires it.)

[AlexWaygood]

Mypy's had a PR open for this since 2023, but with little movement, I think because of the number of ecosystem hits: python/mypy#14717.

While I agree that this check would be useful, we could also consider making the check disabled by default. I don't think soundness "clearly" requires this — for a dict[int, int] object x, we would obviously not emit a diagnostic on x[0], even though the type of x does not guarantee that x actually has a 0 key in it.

[GniLudio]

I don't know whether it's related to this issue or a separate one, but the type of get also isn't correct.

Example

from typing import TypedDict, NotRequired

class MyDict(TypedDict):
    name: str
    foo: NotRequired[int]


my_dict: MyDict = {
    "name": "John", 
    "foo": 5,
}

# detected correctly as 'str'
name = my_dict.get("name") 

# detected as 'Unknown | default'
foo_1 = my_dict.get("hello") 
foo_2 = my_dict.get("hello", 5)

Playground

[GniLudio]

Mypy's had a PR open for this since 2023, but with little movement, I think because of the number of ecosystem hits: python/mypy#14717.

While I agree that this check would be useful, we could also consider making the check disabled by default. I don't think soundness "clearly" requires this — for a dict[int, int] object x, we would obviously not emit a diagnostic on x[0], even though the type of x does not guarantee that x actually has a 0 key in it.

I agree for dict, while thinking that for things like TypedDict (dataclasses, pydantic, etc.) it should be checked by default.
When explicitly defining the types, I expect the typer checker to validate them (to some degree).

[carljm]

While I agree that this check would be useful, we could also consider making the check disabled by default. I don't think soundness "clearly" requires this — for a dict[int, int] object x, we would obviously not emit a diagnostic on x[0], even though the type of x does not guarantee that x actually has a 0 key in it.

Ok, "clearly" was maybe overstating it -- but I agree with @GniLudio that it's different for TypedDict, when you've explicitly said in the type that a given key might be absent, and we will error for accessing keys that you didn't mention at all.

I don't feel super strongly about whether this rule would be enabled by default or not, as long as it's available for those who want it. It's the sort of thing that might belong in a strict mode.

[carljm]

@GniLudio The question about .get return types definitely belongs in a separate issue from this one. (I don't think ty's inference here is wrong, but it is more forgiving -- the other, stricter, option would be object. Both options are "correct", one is just stricter and the other more gradual. Pyrefly and mypy use object, pyright uses Any | default. If you'd like to open an issue to advocate for ty to use object, feel free!)