Repository navigation
TypedDict 'in' narrowing w/o @final #15697
Description
We shouldn't require @final decoration for TypedDicts to narrow them based on the 'in' operator.
Why?
Basically @erictraut's comment.
In #13838, we've added "key in Union[TypedDict, ...]" narrowing for TypedDicts that are marked @final. The reason was to prevent this:
class Mammal(TypedDict):
mammary_glands: int
class Bird(TypedDict):
eggs: int
class Echidna(Mammal):
eggs: int
animal: Mammal | Bird
if 'eggs' in animal:
assert_type(animal, Bird) # WRONG! Could still be a Mammal (a Echidna)
if 'eggs' in animal and 'mammary_glands' in animal:
assert_never(animal) # WRONG! Could still be a Mammal (a Echidna)However, per @erictraut's comment, due to TypedDict being a structural type, we shouldn't consider the class hierarchy when type-matching.
This will be consistent with pyright and TypeScript (Playground Link).
Activity
A5rocks commentedon Jul 18, 2023
Just a note that perhaps, the current behavior can be patched in another (if worse) way?
#7981 (comment) as mentioned here, final typeddict semantics was accepted knowing that you wouldn't be able to consider structural subtyping... as far as I read it?
i.e. this should fail (it doesn't right now):
... but at the same time #15425 was accepted so this new unsafety is probably ok.
ikonst commentedon Sep 2, 2023
@hauntsaninja Judging by your comment here, let's ship it? :)
It would appear that's also how people expect it to be.
gvanrossum commentedon Jan 20, 2024
FWIW there are some typos in the example -- mypy doesn't accept it as written. The last lines probably were intended to be:
ikonst commentedon Jan 21, 2024
Thanks @gvanrossum, edited the PR.