[ty] Don't add identical lower/upper bounds multiple times when inferring specializations#22030
Merged
[ty] Don't add identical lower/upper bounds multiple times when inferring specializations#22030
Conversation
Diagnostic diff on typing conformance testsNo changes detected when running ty on typing conformance tests ✅ |
|
Member
|
Is it worth adding the snippet from astral-sh/ty#1968 (comment) as a regression test, since we obviously don't have coverage for that kind of pattern in mypy_primer? I guess the failure mode is pretty painful (tests just start timing out 😆), but we'd at least notice if we accidentally regressed on this |
Member
Author
Done |
AlexWaygood
approved these changes
Dec 17, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When inferring a specialization of a
Callabletype, we use the new constraint set implementation. In the example in astral-sh/ty#1968, we end up with a constraint set that includes all of the following clauses:In general, we take the upper bounds of those constraints to get the specialization. However, the upper bounds of those constraints are not all guaranteed to be the same, and so first we need to intersect them all together. In this case, the upper bounds are all identical, so their intersection is trivial:
But we were still doing the work of calculating that trivial intersection 7 times. And each time we have to do 7^2 comparisons of the
M*classes, ending up with O(n^3) overall work.This pattern is common enough that we can put in a quick heuristic to prune identical copies of the same type before performing the intersection.
Fixes astral-sh/ty#1968