Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[red-knot] support narrowing on bool(E) #14547

Closed
Tracked by #13694
carljm opened this issue Nov 22, 2024 · 0 comments · Fixed by #14668
Closed
Tracked by #13694

[red-knot] support narrowing on bool(E) #14547

carljm opened this issue Nov 22, 2024 · 0 comments · Fixed by #14668
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented Nov 22, 2024

We currently support type narrowing on various kinds of expressions in a test clause, e.g.

x = 1 if flag() else None

reveal_type(x)  # revealed: Literal[1] | None
if x is not None:
    reveal_type(x)  # revealed: Literal[1]

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).

@carljm carljm added the red-knot Multi-file analysis & type inference label Nov 22, 2024
@carljm carljm self-assigned this Nov 22, 2024
@carljm carljm removed their assignment Dec 2, 2024
carljm pushed a commit that referenced this issue Dec 3, 2024
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant