I've done a first-cut implementation of PEP 646 in pyright 1.1.107. I just published this version, so you can try it by installing the Pyright extension in VS Code.
Specific notes about my current implementation:
* It supports `TypeVarTuple`, which is exported by the typing_extensions.pyi that ships with pyright.
* It supports `Unpack`, also exported by typing_extensions.pyi.
* It does not currently support `*` syntax, since that will be introduced with PEP 637 functionality.
* It does not allow packed usage of a TypeVarTuple. All uses of a TypeVarTuple must be contained with an `Unpack`, and errors are generated if they are not.
* If a TypeVarTuple appears within a subscript for a type annotation, it must be the last entry (i.e. no suffixes). The one exception is `Union`, which allows it to appear anywhere. I figured this was justified because the order of type arguments within a `Union` are not relevant.
* If a TypeVarTuple appears within a class declaration, only one is allowed, and it must be after all other type variables. The order can be forced by including an explicit `Generic` that defines the type parameter ordering.
* At most one TypeVarTuple can appear within a subscript when specializing a class (e.g. `Tuple[Ts1, Ts2]` is an error). The one exception is `Union`, which allows for multiple TypeVarTuples to appear. This creates an ambiguity for the constraint solver, but this ambiguity already exists for traditional TypeVars.
* Type aliases may contain at most one TypeVarTuple, and it must be after all other TypeVars that parameterize the type alias (e.g. `Alias1 = Union[List[T], Tuple[Unpack[Ts]]]` is allowed, but `Alias2 = Union[Tuple[Unpack[Ts]], List[T]]` is an error. Unlike with class declarations, there's no way to force the ordering of type parameters within a type alias, which is somewhat constraining.
* An attempt to assign an open-ended tuple to a TypeVarTuple during constrain solving results in an error.
* A Callable may include a TypeVarTuple within its parameter type list, but only one is allowed, and it must be in the last entry. Other cases are flags as errors.
* If a TypeVarTuple appears more than once in a function signature, the tuples that are assigned to it must match in both length and in type. There is no attempt to widen the type to accommodate differences.
As I anticipated, this was a very large and complex feature to implement. If you're curious, here's the [commit](https://github.com/microsoft/pyright/commit/1d06018908819e17daa08328a64e6e1d5c68c30c).
I've implemented a bunch of test cases. Perhaps these will be of use for other type checker maintainers as when they add support for this PEP. The test samples can be found [here](https://github.com/microsoft/pyright/blob/master/packages/pyright-internal/src/tests/samples/variadicTypeVar1.py). (There are 8 test files and many dozens of test cases for this feature currently.)
Feedback and bug reports are welcome.
Contributor to Pyright and Pylance
Typing-sig mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Member address: firstname.lastname@example.org