You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This task is to add support for the case where the test expression is wrapped in an explicit call to bool(...), e.g. if bool(x is not None):. This is not a common pattern, but pyright supports it, it's always correct, and it's not hard to implement, so there's little reason not to support it.
For any test expression E which we would draw narrowing conclusions from, we should draw the same conclusions from the test expression bool(E).
The text was updated successfully, but these errors were encountered:
Resolves#14547 by delegating
narrowing to `E` for `bool(E)` where `E` is some expression.
This change does not include other builtin class constructors which
should also work in this position, like `int(..)` or `float(..)`, as the
original issue does not mention these. It should be easy enough to add
checks for these as well if we want to.
I don't see a lot of markdown tests for malformed input, maybe there's a
better place for the no args and too many args cases to go?
I did see after the fact that it looks like this task was intended for a
new hire.. my apologies. I got here from
#13694, which is marked
help-wanted.
---------
Co-authored-by: David Peter <[email protected]>
We currently support type narrowing on various kinds of expressions in a test clause, e.g.
This task is to add support for the case where the test expression is wrapped in an explicit call to
bool(...)
, e.g.if bool(x is not None):
. This is not a common pattern, but pyright supports it, it's always correct, and it's not hard to implement, so there's little reason not to support it.For any test expression E which we would draw narrowing conclusions from, we should draw the same conclusions from the test expression
bool(E)
.The text was updated successfully, but these errors were encountered: