Is v1.1.380 no longer accepting isinstance as narrowing for TypedDict intentional?

[gh-andre]

I can see a few things around isinstance changed in v1.1.380, but not quite sure if what's described below is intended behavior or a bug.

In the code below isinstance is effectively being used to cast a specific TypedDict type to MutableMapping, which worked prior to v1.1.380, at which point it's being reported as an error. Is this intentional, and if it is, is it because MutableMapping is not in TypedDict's bases? In the latter case, a warning would be useful that this narrowing attempt is a no-op.

class D(TypedDict):
    x: int

d: D = {"x": 1}
assert isinstance(d, MutableMapping)
del d["x"]         # v1.1.380 reports '"x" is a required key and cannot be deleted'

Thanks

[erictraut]

This is intentional. The assert statement here has no effect here because all TypedDict instances are instances of MutableMapping at runtime.

If you want to define a TypedDict where item d is allowed not to exist (and can therefore be safely deleted), you can use the NotRequired type qualifier.

class D(TypedDict):
    x: NotRequired[int]

[gh-andre]

Thanks for responding.

This is just a simple reproduction case. I do realize how NotRequired works, but in this case I do need MutableMapping specifically, and as far as static typing goes, a TypedDict instance is not allowed to be implicitly cast to a MutableMapping because it may add/delete fields beyond what a specific type dictionary allows, regardless how it is implemented at run time.

So the fact that this isinstance call interprets the argument as a no-op because it is MutableMapping at run time, but then immediately turns around and says that it really is not by not allowing to delete a member of that mutable mapping doesn't sound right.

[erictraut]

What you are doing here is not type safe. You're violating the typing rules for a TypedDict. Adding an assert statement here does not change this fact. It would be concerning if the addition of an assert statement masked a type violation error. That would clearly be a bug.

If you want to override the type checker's logic in this case, you can use a cast call. That's what cast is intended for.

[gh-andre]

You're violating the typing rules for a TypedDict.

You're assuming based on the limited info you have. As long as the lifetime of one instance of the TypedDict ends and another one begins, each of those stretches provides correct static typing assertions.

Having said that, I'm not arguing whether what I'm doing in the real code is type-safe or not at all - it's irrelevant, but instead I'm trying to point out that as far as static typing is concerned, isinstance has certain semantics, which are different from those applied at run time and that in this case either the assert should be reported, as you put it, "not type safe" or accepted as it was before v1.1.380. The very fact that you are saying what you are saying indicates that there's a warning missing there.

Anyway, you answered my question. Thanks for that.

[erictraut]

The isinstance call does not violate any typing rules, so there is no justification for reporting it as unsafe. The del statement is unsafe because it violates the type of d. The absence or presence of an assert statement doesn't change that fact. If it did, that would be highly suspect.

[gh-andre]

Well, a statement alone cannot be deemed safe or unsafe without tracing it back to a declaration or a narrowing statement, since the type checker always evaluates the most recent narrowing statement - the assert in this case, against the operation - the del statement here. Works for even completely broken code like this, as far as static type checking is concerned:

i: int = int(3)
a: str = str("A")
assert isinstance(a, int)
i = a

TypedDict adds complexity in this because typed dictionaries are mutable in nature, so at run time they're effectively MutableMapping, but at static type checking time typed dictionaries cannot be assigned to a MutableMapping implicitly.