Clarification in the choice of __type_variables__ vs __type_param(eter)?s__

[Gobot1234]

It seems to me like all the grammar calls these type parameters or something to that effect. This at least to me seems inconsistent, I'm curious as to why the name __type_variables__ was chosen compared to __type_parameters__ for the tuple of active TypeVarLikes.

[JelleZijlstra]

Reference to the relevant PEP section: https://peps.python.org/pep-0695/#accessing-type-parameters-at-runtime

I agree that __type_param(eter)s__ would be more consistent, as this attribute directly corresponds to the AST node named typeparams (https://peps.python.org/pep-0695/#ast-changes).

[erictraut]

I don't have that strong of an opinion on this issue. The reason I didn't use the term __type_parameters__ is that I figured that term would imply the type parameters for that class as opposed to all active type variables. The distinction is important when considering nested classes or functions.

class Outer[T]:
    class Inner[S]:
        ...

Outer.__type_variables__ contains a value of (T,) and Inner.__type_variables__ contains a value of (T, S) (or (S, T)).

The reason I wanted to make all active type variables available was to enable runtime evaluation of expressions that used those variables (e.g. through eval).

[Gobot1234]

I see, but I do think that the consistency is more important, IMO __type_variables__ could be equally confusing as it can contain ParamSpecs and TypeVarTuples

[erictraut]

Yeah, that's why I didn't use __typevars__ or __active_typevars__. The term "type variable" (at least in my mind) encompasses TypeVar, ParamSpec and TypeVarTuple. But maybe that's not true for others. Like I said, I don't have a strong opinion on the name, so if the person who implements this decides to change it, we can update the PEP accordingly.

[JelleZijlstra]

I proposed __type_params__ in the PEP update (discussed in #10). I think this can be closed.