[ty] Promote Literal types when inferring elements for very large unannotated tuples#22841
Merged
AlexWaygood merged 1 commit intomainfrom Jan 27, 2026
Merged
[ty] Promote Literal types when inferring elements for very large unannotated tuples#22841AlexWaygood merged 1 commit intomainfrom
Literal types when inferring elements for very large unannotated tuples#22841AlexWaygood merged 1 commit intomainfrom
Conversation
AlexWaygood
added
performance
Typing conformance resultsNo changes detected ✅ |
AlexWaygood
changed the title
Literal types when inferring elements for very large unannotated tuplesLiteral types when inferring elements for very large unannotated tuples
|
AlexWaygood
force-pushed
the
alex/big-slow-tuples-2
branch
2 times, most recently
from
0688102 to
4caefe8
Compare
Merging this PR will improve performance by ×4.8
Performance Changes
Comparing 
Footnotes
|
AlexWaygood
force-pushed
the
alex/big-tuple-bench
branch
from
fbb0962 to
7d05ff2
Compare
AlexWaygood
force-pushed
the
alex/big-slow-tuples-2
branch
3 times, most recently
from
689c00c to
e47926e
Compare
AlexWaygood
requested review from
carljm,
dcreager and
sharkdp
as code owners
AlexWaygood
commented
Jan 25, 2026
Comment on lines
+9850
to
+9853
| /// If a tuple literal has more elements than this constant, | ||
| /// we promote `Literal` types when inferring the elements of the tuple. | ||
| /// This provides a huge speedup on files that have very large unannotated tuple literals. | ||
| const MAX_TUPLE_LENGTH_FOR_UNANNOTATED_LITERAL_INFERENCE: usize = 64; |
Member
Author
There was a problem hiding this comment.
64 is a small number[citation needed], but I think it should easily be big enough. I wondered about setting it even lower, e.g. 32. I think there are vanishingly few cases where it's useful to have Literal types preserved for the subelements of a large tuple.
carljm
approved these changes
Jan 27, 2026
Contributor
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
This looks good to me, and I'm fine just going with it.
I do wonder if we couldn't get the same speedup by applying the literal promotion at the point where we are unioning all the tuple members, rather than when we construct the tuple type? Then you'd still get precise type on subscript, just not on iteration/unpacking (where we need the homogenized type).
Member
Author
I think that's possible, yeah. But I'm still not sure what the actual use case is? I can't think of a situation where I'd benefit from getting a precise |
AlexWaygood
force-pushed
the
alex/big-slow-tuples-2
branch
from
e47926e to
262acd5
Compare
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
2 participants
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.
Fixes astral-sh/ty#71. Stacked on top of #22842.
This yields a huge speedup locally when checking https://github.com/MMD-Blender/blender_mmd_tools/blob/6ae13d6039763b6813832622c13da464983e93b3/mmd_tools/m17n.py. The pathological performance on that file wasn't due to inferring a type for the large tuple (that is very fast) -- it was inferring types when subscripting and unpacking that tuple that caused issues. If the tuple is inferred as containing many varied
Literaltypes, subscription and unpacking operations on the tuple involve mapping type operations over huge unions. If the tuple is instead inferred as containing types likeint,strandbytes, however, the unions inferred are much smaller.Promoting
Literaltypes in a very large tuple means that you don't get preciseLiteraltypes out of the tuple when you subscript it. But I think it's very unlikely that you'd want or need a preciseLiteraltype when subscripting a tuple of >64 elements. And if you do... you can give us a type hint, and we'll still respect your intent. (There's some examples in the tests I've added: we'll even respect type hints liketuple[Literal[1], Literal[2], *tuple[int, ...], Literal[65]], and we'll inferLiteraltypes for only the first, second and last elements of the tuple.)As Eric noted in astral-sh/ty#71 (comment), pyright also has a fallback like this to avoid pathological performance for large tuples, but pyright's fallback is much more lossy fallback: it falls back to
tuple[Unknown, ...]for any tuple >256 elements long. I'd prefer not to do that unless we have to, and it seems to me that what I'm proposing here fixes all known pathological performance issues with large tuples without a significant sacrifice of precision.