PEP 646 – Variadic Generics multiple matching variants
Have this example: ``` from __future__ import annotations from typing import Generic from typing import TypeVar from typing import TypeVarTuple Shape = TypeVarTuple("Shape") T = TypeVar("T") T1 = TypeVar("T1") class Array(Generic[*Shape]): ... y: Array[int, *tuple[float, ...], int, str] = Array() def expect_variadic_array(x: Array[int, T, *Shape, T1]) -> Array[*Shape, T, T1]: ... expr = expect_variadic_array(y) which type is expected for expr? ``` Here we can assign: ``` int -> int T -> int (*float empty) *Shape -> empty T1 -> str so return Array[int, str] ``` or ``` int -> int T -> float *Shape -> int T1 -> str ``` so T can be either int or float and *Shape can be either () or (int, float*)
I think it's indeterminate and undefined. I recommend against relying on something like this. Different type checkers will inevitably produce different answers here. Similar ambiguities arise for unpacking and assigning arguments to parameters when indeterminate-length tuples are involved. ``` def func(y: tuple[int, *tuple[float, ...], int, str]): a, b, *c, d = y ``` -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft
Apologies for the slow reply - I'm only just now finally catching up after vacation. If we're substituting: int, *tuple[float, ...], int, str Into: int, T, *Shape, T1 Then I believe what should actually happen is: T = float T1 = str Shape = tuple[*tuple[float, ...], int] The reasoning is that, for arbitrary-length tuples like tuple[float, ...], we assume it always has enough items to fill all the type variables. We chose this behaviour in order to be consistent with existing behaviour for arbitrary-length tuples: t: tuple[int, ...] a, b = t # Valid a, b, c = t # Also valid def bar(a: int, *b: int): ... bar(*t) # Valid Note that this last example is somewhat surprising - `bar` supposedly has to take at least one argument, but the arbitrary-length tuple we're passing in could have zero elements. But *shrug* this is the way it is. This is admittedly rather under-documented. We're trying to amend PEP 646 in https://github.com/python/peps/pull/2883 with the details of how this works. If the SC decides against revising an already-accepted PEP, though, we'll try and find somewhere else to document it. On Wed, 2 Nov 2022 at 17:03, Eric Traut <eric@traut.com> wrote:
I think it's indeterminate and undefined. I recommend against relying on something like this. Different type checkers will inevitably produce different answers here.
Similar ambiguities arise for unpacking and assigning arguments to parameters when indeterminate-length tuples are involved.
``` def func(y: tuple[int, *tuple[float, ...], int, str]): a, b, *c, d = y ```
-Eric
-- Eric Traut Contributor to Pyright & Pylance Microsoft _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: mrahtz@google.com
participants (3)
-
andrey.matveev.mano＠gmail.com -
Eric Traut -
Matthew Rahtz