(Copying and pasting from the previous PR; haven't thought about Jelle's suggestion yet)

@pradeep90 In the previous review, you mentioned you'd prefer to avoid this middleman class, instead for example making it so that starring a TypeVarTuple results in an instance of Unpack.

That example solution seems suboptimal to me for two reasons:

1. In a few places in the rest of typing.py, we want to check whether an object is an unpacked TypeVarTuple, and instance(obj, UnpackedTypeVarTuple) seems more readable to me than isinstance(obj, Unpacked).
2. It seems potentially confusing to have Unpack both be an operator and an object.

Another option would be something like:

class TypeVarTuple:

    def __init__(self, name, _starred=False, _id=None):
        self.name = name
        self._starred = starred
        self._id = id

    def __iter__(self):
        yield TypeVarTuple(self.name, _starred=True, _id=id(self))

    def __eq__(self, other):
        if self._id is not None and other._id is not None:
            return self._id == other._id
        else:
            return object.__eq__(self, other)  # Not sure whether this is right, but you get the gist

    def __repr__(self):
         return ('*' if self._starred else '') + self.name

I lean away from this solution too because I feel like manually managing IDs could lead to subtle bugs, and isinstance(obj, UnpackedTypeVarTuple) is still simpler than isinstance(obj, TypeVarTuple) and obj._starred, but WDYT?

Jelle's argument that Unpack should work with arbitrary types at runtime convinced me that your approach is the way forward :) Have re-implemented Unpacked with _SpecialForm, as Jelle suggested. How does it look to you now?

@pradeep90 You mentioned in the previous review you'd prefer to have this inherit from _TypeVarLike. I'm not sure I understood your reasoning - could you explain what you meant by "The flags are things that the typechecker has to deal with"?

I meant there seems to be no reason why TypeVarTuple can't inherit from _BoundVarianceMixin (previously TypeVarLike). Someone can use isinstance(x, TypeVarLike) instead of hardcoding isinstance(x, (TypeVar, ParamSpec)) and thus missing out TypeVarTuple.

The downside is that TypeVarTuple("Ts", bound=...) or covariant=True will be valid at runtime. That's fine. We want the runtime to be as lenient as possible so that we can specify the behavior of bound in the future. The counter-argument is that we might want a different name such as item_bound for TypeVarTuple.

I'm ok with either.

Can you try substituting with B[Unpack[Ts]] and B[Unpack[tuple[str, ...]]]

A for-loop over a list of arguments might make this more succinct and easier to follow.

error_cases = [
  ((T1, T2), (int,)), 
  ...
]
for typevars, params in error_cases:
  self.assertRaises(TypeError, ...)

Same for these tests - we could have a list of inputs and expected outputs.

Do we need to test for the type arguments (called "params" here) having Unpack[...]? The cases are Unpack[tuple[int, str]], Unpack[tuple[int, ...]], Unpack[Ts], and combinations.

Things get a bit complicated with tuple[int, ...]. For example, when the expected types are (T1, T2), we should have T1=int, T2=int. When the expected types are (T1, *Ts, T2) and the type argument is (int, Unpack[tuple[str, ...]]), we should have T1=int, Ts=tuple[str, ...], T2=str.

It would be great to avoid implementing all this logic, but it looks like GenericAlias demands this behavior at runtime so that people can do MyAlias[<...>] == <the instantiated type>, so we may not have a choice.

This looks a bit dodgy.

Edit: Didn't mean it was wrong. Just looks weird to see a combined tuple of the parameter and return types because I'm not familiar with the format behind __args__ for Callable

Wait, Dict[*<...>] isn't a valid type, right? Otherwise, someone may write Dict[*Ts] and that may fail (during type-checking).

Even if Dict[*tuple[int, str]] ends up being correct at runtime, I think we'd want to discourage this. Could you use an Array instead?

Could you describe the three possible uses (TypeVar, ParamSpec, and TypeVarTuple) in the class docstring and the __init__ docstring? The name BoundVarianceMixin and the docstring feel a bit cryptic.

(This is assuming we use this mixin for TypeVarTuple - discussed in comment below.)

_type_check seems to be used in two kinds of places:

1. _type_check is used on the type arguments for SpecialGenericAlias.
2. Apart from the above, _type_check is used on the type arguments of a bunch of special forms like Optional, Final, Union, etc.

IIUC, we care about variadic tuples in (1) but not (2).

For (1), if we have MyAlias = Array[*Ts], we want to be able to instantiate the alias as MyAlias[int, *Ts2, str]. That suggests what we want above is Unpack.

For (2), with the current code, we'd accept x: Final[Ts] or Optional[Ts], which again isn't valid. Note that even Optional[*Ts] is wrong. Likewise, BoundVarianceMixin uses _type_check on the bound. This means we'd end up accepting T = TypeVar("T", bound=Ts).

(I haven't tested the above, so I could be way off.)

I see two ways ahead:
(a) replace TypeVarTuple with Unpack above and just live with the invalid uses like Optional[*Ts].
(b) make SpecialGenericAlias check for Unpack on top of _type_check so that it can accept MyAlias[int, *Ts, str] but things like Optional[*Ts] would be ruled out.

What do you think? If that sounds right, could you add tests for these cases?

Can we leave out the runtime arity checking for TypeVarTuple? I'm in favor of keeping the runtime stuff minimal and letting the type checkers handle cases as needed. Otherwise, we're bound to miss some case and cause problems (or make it harder to extend this in the future).

Did you have a use case in mind for the runtime errors?

I meant there seems to be no reason why TypeVarTuple can't inherit from _BoundVarianceMixin (previously TypeVarLike). Someone can use isinstance(x, TypeVarLike) instead of hardcoding isinstance(x, (TypeVar, ParamSpec)) and thus missing out TypeVarTuple.

The downside is that TypeVarTuple("Ts", bound=...) or covariant=True will be valid at runtime. That's fine. We want the runtime to be as lenient as possible so that we can specify the behavior of bound in the future. The counter-argument is that we might want a different name such as item_bound for TypeVarTuple.

I'm ok with either.

@Fidget-Spinner commented on the parallel typing-extensions tests (python/typing#963) that it's not really clear what these are testing. I agree, so over there I'm planning to make tests like this also check that __args__ is correct.

Would be good to also test A[int, str, float, bool], where the Ts maps to multiple types.