Inconsistent behavior when validating type parameter substitutions

[Viicos]

Bug report

Bug description:

There are currently three different cases (two of them being closely related) where type parameters can be substituted/parameterized with concrete types:

• On a user-defined generic class:

  class MyGeneric[T1, T2]: ...
  
  alias = MyGeneric[int, str]

• On an already parameterized alias (following the previous example):

  temp_alias = MyGeneric[int, T2]
  alias = temp_alias[str]

• On a PEP 695 type alias:

  type MyAlias[T1, T2] = dict[T1, T2]
  
  gen_alias = MyAlias[int, str]

---

All of these three cases have slightly different behavior. The one that seems to be the most accurate is the second one. As alias is a _GenericAlias instance, parameterizing it will call _GenericAlias.__getitem__. There is a bunch of logic in there, and it seems that both __typing_prepare_subst__ and then __typing_subst__ (which is only doing type check assertions) are being called.

However, the first case is not making the calls to __typing_subst__, meaning the following would unexpectedly work:

class A[T, **P]: ...

A[int, str]
# ok at runtime, should fail as `P` should be substituted with a valid parameter expression
# (another ParamSpec, the ellipsis, a list/tuple of types or a Concatenate form).

If you do the same on a _GenericAlias instance (matches the second case), an error is raised:

alias = A[T, P]

alias[int, str]
# TypeError: Expected a list of types, an ellipsis, ParamSpec, or Concatenate. Got <class 'str'>

This leads us to the first point: should we apply the same logic between these two cases? To avoid breaking changes, we might have to consider forward references:

class A[T, **P]: ...

A[int, 'ForwardParamSpec']

ForwardParamSpec = ParamSpec('ForwardParamSpec')

So perhaps we can exclude ForwardRef from the type check in ParamSpec.__typing_subst__ (note that it already doesn't work for the second case).

I'll also note that having __typing_subst__ not called is not the only difference. For instance, the second case also calls _unpack_args() on the passed args, while the first case doesn't ¹

---

Onto the last case (PEP 695 type aliases), currently no validation is performed whatsoever:

type MyAlias[T1, T2] = dict[T1, T2]

MyAlias[int]  # no error

So the second point is: should we apply the same logic as in case 1/2? Again, I don't know if applying the same logic here on type aliases is going to introduce any breaking changes concerns?

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Footnotes

1. Here is an example of how this manifests: https://gist.github.com/Viicos/db10da58914809a87c0a82c1b2f19162 ↩

[JelleZijlstra]

I don't really like how we attempt to provide precise type parameter substitutions at runtime. The logic gets really complicated with TypeVarTuple and ParamSpec involved, the gain from doing all this logic at runtime is limited, and the risk is somewhat large (if we get it wrong, correct substitutions may fail). That's why I went with the simpler solution of not doing any validation when I implemented PEP 695.

Backward compatibility means we need to be careful with any changes here, so I don't have a concrete suggestion for what to do, but that's my general opinion.

[Viicos]

The logic gets really complicated with TypeVarTuple and ParamSpec involved

Yes, especially with TypeVarTuple. ParamSpec is actually pretty similar to TypeVar, apart from the fact that a valid parameter expression must be used and the special case when it is the sole parameter in the list.

The logic gets really complicated with TypeVarTuple and ParamSpec involved, the gain from doing all this logic at runtime is limited, and the risk is somewhat large (if we get it wrong, correct substitutions may fail).

That's reasonable, altough it seems that the substitution behavior in the second case is correct against all the examples from the various PEPs (but yeah there's still cases that can be missed).

That's why I went with the simpler solution of not doing any validation when I implemented PEP 695.

I'm trying to define a utility function mapping parameters to their respective substituted type(s) (i.e. returning dict[TypeVarLike, Any]). In the case of PEP 695 type aliases, not having any substitution logic applied is actually fine as I can do the logic manually (the one from the second case). However, it's going to be more challenging for the first use case, where the substitution is "halfway done" in some way.