Closed RobertCraigie closed 1 month ago
This behavior is expected. For a full list of supported type guards in pyright, refer to this documentation. Discriminated objects are supported only with the pattern x.y == LN
where LN
is a literal expression or None
and x
is a type that is distinguished by a field or property with a literal type. You can also use x.y is True
, but discriminated objects won't work with a simple truthy/falsy check.
I explored supporting this with the truthy/falsy check, but it measurably slowed type analysis (and therefore completion suggestions, etc.). The list of supported type guard patterns is carefully curated to strike a balance between usability, maintainabilitiy, and performance.
I think it's a bit unusual to use a bool literal to discriminate between object types. More typical would be a str
, int
, or enum type that scales to more than just two variants. In those cases, a truthy/falsy check wouldn't make sense.
I'm going to decline this enhancement request for now, but I'm willing to reconsider it in the future if there's sufficient demand for this pattern. It's possible that I could mitigate the performance impact, but that would require some deeper investigation.
Thanks for looking into this!
Out of curiosity did you check what the performance impact was for just supporting bool
for truthiness type narrowing?
Describe the bug
I'd expect the types in the second if condition to be the same as the first as
message.invalid == True
is equivalent tomessage.invalid
in this case.Additional context
Mypy's behaviour is actually the inverse surprisingly (playground).
VS Code extension or command-line
CLI 1.1.371