GeezerVison

Checking for something like _is_paramspec would be clearer IMO, but we don't have that function and it's kind of a waste to make a function just for this one-time use.

This code will gone after moving the logic in ParamSpec.__getitem__ in #27511.

I am planning first to fix most bugs and to cover more cases by tests, and only then apply #27511, so we may not need to backport it.

Hmm I feel a little strange about this. I feel that the new form is correct, but I also feel the old form should work. There's not much ambiguity in using the old form.

The PEP explicitly claim that only substituting ParamSpec with the parameters expression should be accepted. It will also simplify the future code.

Ah ok I see it now:

def f(x: X[int, int]) -> str: ...                    # Rejected

Thanks for the reminder.

Good test! 👍

This isn't a critique of your PR, but a minor regret of mine: Looking at G5, G6, G7, I realized their __args__ should be (int, str, bool) or (int, ), etc.; not nested tuple with types. Nested tuple makes repr weird, and also nested tuple means any nested TypeVar or ParamSpec won't appear in __parameters__ and so can't be substituted.

I don't remember what made me code it like that back then, but it could be me not wanting to make the _GenericAlias.__getitem__ code complicated just for ParamSpec.

It does not work for user generics because they can have more than one ParamSpec. For example:

class X(Generic[P1, P2]):
    f: Callable[P1, int]
    g: Callable[P2, str]
G1 = X[[int, str], [bytes]]
G2 = X[int, [str, bytes]]
assert G1.__args__ == ((int, str), (bytes,))
assert G2.__args__ == ((int,) (str, bytes))

If flatten arguments, __args__ of G1 and G2 would be the same ((int, str, bytes)). But they are clearly different types.

I'll add a special test for this.

Right, thanks for pointing that out! I forgot there was ambiguity with multiple ParamSpec. Hopefully some future PEP makes this clearer.