``typing.List`` includes ``ParamSpec`` in ``__parameters__`` but the builtin ``list`` doesn't. The behavior of the latter is correct, as PEP 612 states that: "As before, parameters_expressions by themselves are not acceptable in places where a type is expected".

https://www.python.org/dev/peps/pep-0612/#valid-use-locations

This patch just makes the typing version same as the builtin version by excluding ``ParamSpec`` from ``__parameters__`` (except for Concatenate, Callable, and Generic).

New changeset c55ff1b352f8b82184f80d9dea220e832691acfc by Miss Islington (bot) in branch '3.10':
bpo-44098: Drop ParamSpec from most ``__parameters__`` in typing generics (GH-26013) (#26091)
https://github.com/python/cpython/commit/c55ff1b352f8b82184f80d9dea220e832691acfc

All patches have landed. Thanks Guido!

I think that List[P] should be illegal at first place.

Yeah, but we shouldn't go out of our way to reject it. Especially since in 3.11 we'll likely have something equivalent to PEP 563 or PEP 649 (the SC is thinking deep about this right now) and either of those means that usually it won't be evaluated at all anyway (you'd have to call get_type_hints() with PEP 563, or use __annotations__ with the other).

I am writing a patch which generalizes and significantly simplifies the code for type variables and parameter specifications substitution, and opens a way for more runtime validation. But it is incompatible with these changes.

@Serhiy, could you please briefly describe what you are planning? I'm guessing you're generalizing for _TypeVarLike?

My main concern is that we should have as few differences between builtin and typing types as possible. typing.List is deprecated and set to remove in Python 3.13/14, so I'm hoping the transition will be fairly painless.

Originally, the builtin types supported ParamSpec, but I removed that in GH-25449 for various reasons listed in that PR.

See issue44796.