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 if x and if not x #14550

Open
Tracked by #13694
carljm opened this issue Nov 22, 2024 · 7 comments
Open
Tracked by #13694

[red-knot] support narrowing on if x and if not x #14550

carljm opened this issue Nov 22, 2024 · 7 comments
Assignees
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented Nov 22, 2024

This is trickier than it might appear; the complexities are discussed in #13694 (comment)

It will likely require adding a new method Type::exclude_always_truthy which returns a new Type that excludes all inhabitants of the previous type that are known to always be truthy.

@carljm carljm added the red-knot Multi-file analysis & type inference label Nov 22, 2024
@carljm carljm self-assigned this Nov 22, 2024
@cake-monotone
Copy link
Contributor

cake-monotone commented Nov 23, 2024

May I work on this?

I noticed the comment about using an enum for narrowing (e.g., EliminateNonTruthy). Did you perhaps mean EliminateNonFalsy or EliminateTruthy instead?( if not x)

Would it be simpler to just define it as Falsy? I feel that the enum name doesn't necessarily need to include the notion of negation. What do you think about this approach?

If your intention is to emphasize that intersections with literals must always be negative, I can proceed as you suggested.

@MichaReiser
Copy link
Member

@cake-monotone We have someone new starting next week and I think Carl created this task deliberately for them. That's why he assigned it to himself.

@cake-monotone
Copy link
Contributor

Ah! I see! Thanks for your comment! I haven’t started working on it.

@MichaReiser
Copy link
Member

I haven't done much typing work myself so I don't have a good sense for how "hard" some of these tasks are but if you're interested in contributing, you could consider tackling one of the special form tasks or take a look at any other task labeled with help-wanted

@carljm
Copy link
Contributor Author

carljm commented Nov 23, 2024

@cake-monotone Micha is right about why I created this issue and assigned it to myself, but that said: if you are interested in working on this, please go ahead, that would be great! Given your past work I have no doubt you'll do a good job with it. We have plenty of things to work on, I won't have any trouble finding a replacement task for our new hire. (And this isn't one of the initial starter tasks, so they wouldn't have gotten to it for a few weeks anyway.)

Please do confirm if you start working on it, and I will assign it to you.

@carljm
Copy link
Contributor Author

carljm commented Nov 23, 2024

Regarding the naming, I think you are right, it will be clearer to use a name like I suggested in the description of this issue (exclude_always_truthy). It is important to reflect that this is a negative intersection (that is, we are excluding all types known to always be truthy, which is different from intersecting with Falsy.)

But the word "exclude" already serves that purpose, it's just confusing to use another negative beyond that.

@cake-monotone
Copy link
Contributor

I got it. Thanks for clarifying and for your encouragement! I’ll start working on this—feel free to assign it to me.

Also, thanks to MichaReiser for pointing out other potential tasks. I really appreciate it!

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

No branches or pull requests

3 participants