[ty] Have typing.Unpack[tuple[]] behave more like *tuple[]#23651
Merged
AlexWaygood merged 5 commits intoastral-sh:mainfrom Mar 2, 2026
Merged
[ty] Have typing.Unpack[tuple[]] behave more like *tuple[]#23651AlexWaygood merged 5 commits intoastral-sh:mainfrom
typing.Unpack[tuple[]] behave more like *tuple[]#23651AlexWaygood merged 5 commits intoastral-sh:mainfrom
Conversation
Unpack[tuple[]] behave like *tuple[]typing.Unpack[tuple[]] behave like more like *tuple[]
Typing conformance results improved 🎉The percentage of diagnostics emitted that were expected errors increased from 85.77% to 85.80%. The percentage of expected errors that received a diagnostic increased from 77.22% to 77.40%. Summary
True positives addedDetails
|
|
Memory usage reportMemory usage unchanged ✅ |
Merging this PR will improve performance by 13.23%
Performance Changes
Comparing 
Footnotes
|
|
| Lint rule | Added | Removed | Changed |
|---|---|---|---|
unused-type-ignore-comment |
0 | 11 | 0 |
| Total | 0 | 11 | 0 |
typing.Unpack[tuple[]] behave like more like *tuple[]typing.Unpack[tuple[]] behave more like *tuple[]
AlexWaygood
approved these changes
Mar 2, 2026
Member
AlexWaygood
left a comment
There was a problem hiding this comment.
Thank you very much!!
These appear to be all cases where now that Unpack[tuple] is being treated as *tuple we are now not Unioning a TodoType into the resolution of typeshed definitions of these functions: python/typeshed@main/stdlib/os/init.pyi#L1342 which makes these seem like they are true positives
Unfortunately these were actually false positives, due to the fact that we don't yet support unpacked tuples used as annotations for *args arguments. These need to be treated specially in our call-binding machinery: whereas *args: int means "all arguments passed to this variadic parameter must be an int", *args: *tuple[int, *tuple[str, ...]] or *args: Unpack[tuple[int, Unpack[tuple[str, ...]]]] means "the first argument passed to this variadic parameter must be an int, and all following arguments passed to this variadic parameter must be strs".
I pushed an easy workaround that gets rid of the false positives.
carljm
added a commit
that referenced
this pull request
Mar 2, 2026
* main: (30 commits) [ty] Introduce `types::bool`, `types::context_manager` and `types::iteration` (#23681) [ty] Move `KnownInstanceType`, and related types, to a new `known_instance.rs` submodule (#23680) [ty] Add `invalid-enum-member-annotation` lint rule (#23648) [`ruff`] Fix false positive for `re.split` with empty string pattern (`RUF055`) (#23634) [ty] Move `UnionType` and `IntersectionType` to a new `types::set_theoretic` submodule (#23678) [ty] Add unbound type variable detection in annotations (#23641) [ty] Remove `specialize_constrained` from constraint set module (#23677) [ty] Add partial support and validation for `Unpack` when used with tuple types (#23651) Update prek dependencies (#23661) [ty] make `StaticClassLiteral::explicit_bases` converge better in cycles (#23601) Improvements to CLAUDE.md (#23633) [ty] Move subscript logic out of `builder.rs` (#23653) Update Artifact GitHub Actions dependencies (#23676) Update actions/attest-build-provenance to 4.1.0 (#23654) Update Rust crate clearscreen to v4.0.5 (#23664) fix renovate `actions/*-artifact` updates (#23675) Update Rust crate clap to v4.5.60 (#23663) Update Rust crate unicode-ident to v1.0.24 (#23668) Update Rust crate anyhow to v1.0.102 (#23662) Update Rust crate pyproject-toml to v0.13.7 (#23666) ...
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
3 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.
Summary
@AlexWaygood recently added support for detecting some invalid unpacking for
*tuplein: #22884.This PR leverages that work and now threads
typing.Unpackthrough this logic whenUnpackis used on a tuple, this removes aTodoTypebranch and resolves some conformance suite expectations.Test Plan
Add complementary assertions in mdtests to match the assertions added for
*tuplecaseEcosystem analaysis
Added only
execlp,execlexecleexeclpexeclexeclpThese appear to be all cases where now that
Unpack[tuple]is being treated as*tuplewe are now not Unioning aTodoTypeinto the resolution of typeshed definitions of these functions: https://github.com/python/typeshed/blob/main/stdlib/os/__init__.pyi#L1342 which makes these seem like they are true positivesRemoved only
unused-type-ignoregoing away. These look to be the same as above, thetype-ignoresoften don't look to be be directly related to Unpack but tracing back a variable/function call have anUnpacksuch as: https://github.com/sympy/sympy/blob/master/sympy/polys/puiseux.py#L56 which are now meaning theTodoTypeisn't suppressing a real diagnostic thus making the type ignore no longer unusedRest
Flaky