conformance: change generics_typevartuple_args.py case#2203
conformance: change generics_typevartuple_args.py case#2203JelleZijlstra wants to merge 2 commits intopython:mainfrom
Conversation
I don't think this case should error; a type checker can solve Ts to something like (object,) or (int | str,). This is not all that different from the first call to func4(), where the two calls with (0,) and (1,) lead to Ts being solved to a common supertype.
|
|
||
| func4((0,), (1,)) # OK | ||
| func4((0,), (1, 2)) # E | ||
| func4((0,), ("1",)) # E |
There was a problem hiding this comment.
To me it seems most consistent with how typevar solving works everywhere else in the type system to actually specify that this should not be an error. It looks like that would match the behavior of mypy and zuban, but not of pyrefly or pyright.
If there's opposition to that change, I would still probably favor leaving this in, with E? and a comment -- that seems more useful to future discussion of this case.
(As far as I can see from a quick scan, this behavior was not specified in the PEP.)
There was a problem hiding this comment.
This comes from this section of the spec, which was copied from the PEP. This section was added to the PEP late in the process — after I had reviewed the PEP and implemented it in pyright. I was very unhappy when I learned about the addition because, as you point out, it introduces an inconsistency with the way that TypeVar solving works in other cases.
Line 76 of the conformance test is arguably different than the special case spelled out in the spec, which says "If the same TypeVarTuple instance is used in multiple places". Ts appears only once in the signature of func4, but because it is defining the type of a variadic parameter, Ts appears multiple times from the perspective of a constraint solver. Constraints are supplied for each argument that maps to that variadic parameter.
Consider the following example. The spec clearly dictates that the call to func3 is an error. I think the call to func4 should likewise be an error.
def func3[*Ts](a: tuple[*Ts], b: tuple[*Ts], /): ...
func3((1,), ("a",)) # Clearly an error according to the spec
def func4[*Ts](*args: tuple[*Ts]): ...
func4((1,), ("a",)) # For consistency, should be an error tooSo, unless we amend the spec, I think the conformance test should remain as is (with the possible addition of a better comment to explain the above).
I'm in favor of modifying the spec and removing this entire section.
There was a problem hiding this comment.
Ah, thanks @erictraut -- I missed that section when scanning the PEP text. I agree that that section of the PEP/spec text is applicable here, and also that it's unfortunately inconsistent with the usual behavior of Python typevar solving. I'm not sure any of the PEP authors are still active in Python typing, or we could ask what motivated that late addition to the PEP text.
There are use cases for stricter typevar solving that doesn't ever synthesize wider types, but those use cases exist for regular typevars too, not just for variadic ones. So it seems better to go for consistency, and introduce a new orthogonal type system feature for stricter solving. (One possible shape for that feature is a NoInfer qualifier -- though it's not clear how that could be used in the *args case.)
4 participants
I don't think this case should error; a type checker can solve Ts
to something like (object,) or (int | str,). This is not all that
different from the first call to func4(), where the two calls with (0,)
and (1,) lead to Ts being solved to a common supertype.