Fix various bugs in TypeVarTuples with defaults#21544
Open
ilevkivskyi wants to merge 1 commit into
Open
Conversation
Contributor
|
Diff from mypy_primer, showing the effect of this PR on open source code: static-frame (https://github.com/static-frame/static-frame)
+ static_frame/core/node_re.py:54: error: Unused "type: ignore" comment [unused-ignore]
+ static_frame/core/node_re.py:59: error: Unused "type: ignore" comment [unused-ignore]
+ static_frame/core/node_dt.py:120: error: Unused "type: ignore" comment [unused-ignore]
+ static_frame/core/node_dt.py:124: error: Unused "type: ignore" comment [unused-ignore]
+ static_frame/core/node_str.py:93: error: Unused "type: ignore" comment [unused-ignore]
+ static_frame/core/node_str.py:98: error: Unused "type: ignore" comment [unused-ignore]
|
Member
Author
|
Not 100% sure what happened with |
JukkaL
reviewed
May 27, 2026
Collaborator
JukkaL
left a comment
JukkaL
left a comment
There was a problem hiding this comment.
Not a full review -- I found a few potential issues.
| 'Implicit generic "Any". Use "{}" and specify generic parameters' | ||
| ) | ||
| NO_CYCLIC_DEFAULT: Final = "Cyclic type variable defaults are not supported" | ||
| NO_DEFAULT_AFTER_TYPEVAR_TUPLE: Final = "A type variable with default cannot follow TypVarTuple" |
Collaborator
There was a problem hiding this comment.
Typo: TypVarTuple -> TypeVarTuple
| reveal_type(a) # N: Revealed type is "__main__.ClassC2[builtins.str, Unpack[builtins.tuple[builtins.float, ...]]]" | ||
| # reveal_type(b) # Revealed type is "__main__.ClassC2[builtins.int, Unpack[builtins.tuple[builtins.float, ...]]]" # TODO | ||
| reveal_type(c) # N: Revealed type is "__main__.ClassC2[builtins.int]" | ||
| reveal_type(b) # N: Revealed type is "__main__.ClassC2[builtins.int]" |
Collaborator
There was a problem hiding this comment.
This seems to lose the default Unpack[builtins.tuple[builtins.float, ...]] for Ts3 -- this is different from the original commented-out expectation.
| # reveal_type(b) # Revealed type is "Tuple[builtins.int, Unpack[builtins.tuple[builtins.float, ...]]]" # TODO | ||
| reveal_type(c) # N: Revealed type is "tuple[builtins.int]" | ||
| reveal_type(a) # N: Revealed type is "tuple[builtins.str, Unpack[builtins.tuple[builtins.float, ...]]]" | ||
| reveal_type(b) # N: Revealed type is "tuple[builtins.int]" |
Collaborator
There was a problem hiding this comment.
This also loses the default and changes the expectation from the original. Is this intentional?
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 a bunch of TODOs in tests.
Fixes #20449
Couple non-trivial things here:
First, I prohibit (regular) type variables with defaults that appear after a
TypeVarTuple. The PEP and the spec are clear that these are ambiguous and invalid. But, because they are ambiguous, we can't simply give the error, since otherwise various parts of code will behave in weirdly inconsistent ways. Therefore, I completely erase ambiguous type variables out of existence, 1984 style.Second, couple commented-out tests cases suggested that
TypeVarTupledefaults should be used in cases where*tuple[()]would be used as a value otherwise, plusFoo[X, Y]andFoo[X, Y, *tuple[()]]should be interpreted differently. I don't see anything about this in the PEP/spec, and I don't like this. I think the default should be used only in cases whereAnyorNeverwould be used otherwise.