-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[ty] Use "typeguard constraints" for two kinds of tuple narrowing #22348
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
base: main
Are you sure you want to change the base?
Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
|
Maybe some small speedups of 1-2%: https://codspeed.io/astral-sh/ruff/branches/alex%2Ftgard-narrow?utm_source=github&utm_medium=check&utm_content=details |
|
Nope, that's gone completely after pushing another commit to the PR. Just noise in terms of the performance impact, then. Still, I feel like this change makes sense conceptually. |
Summary
Since we've already filtered the union in these locations, it seems like needless overhead to then intersect the previous union with the filtered union. We know what that intersection will simplify to: it will simplify to the filtered union. So rather than using a regular intersection-based constraint, we can use a "typeguard constraint", which will just directly replace the previous type with the new type instead of creating an intersection.
Test Plan