Solve class-level TypeVarTuples in explicit self-types - #22023
Open
Dextheking1 wants to merge 2 commits into
Open
Dextheking1 wants to merge 2 commits into
Dextheking1 wants to merge 2 commits into
Conversation
) When a method of a TypeVarTuple-generic class declares an explicit self-type with extra arguments around the unpack, e.g. `def add(self: "A[*TS, int, int]") -> "A[*TS, int]"`, bind_self() left the class-level *TS alone and expand_type_by_instance() later spliced the whole instance argument tuple into *TS. A(1, 2, 3).add() was therefore revealed as A[Literal[1]?, Literal[2]?, Literal[3]?, int] instead of A[Literal[1]?, int]. Fix: in bind_self(), also solve class-level TypeVarTuples appearing in the self-type against the receiver type, and substitute the solutions into the signature before dropping the self argument. Class-level type variables that cannot be solved are left alone for expand_type_by_instance() as before. Regular (non-variadic) class type variables are unaffected: their positions are fixed, so the existing substitution stays correct for them. Adds regression test testTypeVarTupleExplicitSelfTypeWithExtraArgs.
…ypes (fix python#21878) A class-level TypeVarTuple cannot take two different values in the same scope (see discussion in python#21878). In `def add(self: "A[*TS, int, int]")`, TS is already bound to the instance's full argument tuple, so the self-type means e.g. A[1, 2, 3, int, int] for an A[1, 2, 3] receiver, and the call must be rejected with "Invalid self argument" instead of revealing a bogus A[1, 2, 3, int]. check_self_arg() now substitutes the class type variables in an explicit self-type containing a TypeVarTuple unpack using the receiver, before the overlap/subtype checks. Method-level type variables are unaffected, and self-types without an unpack keep the previous behavior. This replaces the inference-based approach from the previous commit on this branch, which solved *TS as the argument prefix. Adds regression test testTypeVarTupleExplicitSelfTypeWithExtraArgs.
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
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
1 participant
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.
Closes #21878.
A class-level
TypeVarTuplecannot take two different values in the same scope (see discussion in #21878). Indef add(self: "A[*TS, int, int]"),TSis already bound to the instance's full argument tuple, so the self-type means e.g.A[1, 2, 3, int, int]for anA[1, 2, 3]receiver. Previously the unpack made the self-argument overlap check vacuously succeed, andexpand_type_by_instance()then spliced the whole instance argument tuple into*TS, revealing a bogusA[Literal[1]?, Literal[2]?, Literal[3]?, int].check_self_arg()now substitutes the class type variables in an explicit self-type containing aTypeVarTupleunpack using the receiver, before the overlap/subtype checks, soA(1, 2, 3).add()is rejected withInvalid self argument. Method-level type variables are unaffected, and self-types without an unpack keep the previous behavior.Adds regression test
testTypeVarTupleExplicitSelfTypeWithExtraArgs.