* Change name of `MATCH_CLASS` to `MATCH_POSITIONAL`.
* Drop `__attributes__` and use `__match_args__` instead.
* For `MATCH_DEFAULT`, `__match_args__` acts a map from positions to names.
* For `MATCH_POSITIONAL`, `__match_args__` acts a map from names to positions.
* Change semantics of `MATCH_DEFAULT` when match class patterns to those of PEP 634.
* Update translations.
* Further expand examples
This is the more-or-less final version now. I'll do one last read-through to confirm everything's consistent, then post in typing-sig to confirm it's ready for the Steering Committee.
Semantic changes:
* Remove support for type variable tuples in `Union`. Apparently the implementation would be tricky in Pyre because of special-casing around `Union`. That could be evidence that it would be tricky in Mypy and pytype. Since we don't have a specific use-case in mind, I think this is fine.
* Support concatenation in `Callable`. Pradeep pointed ou that `ParamSpec` doesn't cover all potential use-cases because it doesn't support concatenating suffixes (in turn because `ParamSpec`s can contain keyword arguments, and concatenation is positional).
Readability changes:
* Remove the section on a full `Array` example. We've moved the important thing here - an explicit confirmation that `Array` can be generic in both datatype and shape - to the beginning of the PEP to make it more obvious. We've removed the `Ndim` thing after someone pointed out that e.g. `Ndim[Literal[2]]` would be incompatible with `Shape[Any, Any]`; I just don't think it's going to work. All that's left is the aliases, which we've moved into the Aliases section itself.
Other changes:
* Fill out Backwards Compatibility section.
* Reference initial CPython implementation.
Readability changes:
* Tweak framing to also acknowledge that variadic generics have been wanted for other things too (though as far as I've been able to tell there isn't a consistent enough pattern to the other use cases to justify including them in the PEP)
* Move the Array example much earlier (both because reading a detailed example is going to be a faster way of getting the gist for people in a hurry, and because we want to make it clear to numerical computing folks from the start that we can also specify a datatype here). (We still have a more detailed Array example later; I'm leaving that there for the time being pending some discussion with Pradeep, but eventually I guess it'll be removed and absorbed into this earlier example)
* Make it clear that other types can appear in `Union` alongside `TypeVarTuple` instances.
Semantic changes:
* Disallow a `Union` of more than one type variable tuple (I thought this would be easier than concatenation of more than one type variable tuple, but Pradeep points out it could still get hairy for type checkers, so disallow it for now to be on the safe safe)
Also some *more* type fixes...
Mark Shannon
Irit Katriel
Batuhan Taskaya
Sumana Harihareswara
Victor Stinner
Thomas Kluyver
Matthew Rahtz
Christian Heimes
Inada Naoki
Brett Cannon
Dustin Ingram
Dave Brondsema
Pablo Galindo
Sean Lockwood
Jacob Walls
David Foster
Naren Santhanam
Ken Jin
Dennis Sweeney
Florian Bruhin
Yury Selivanov