After some sleep, I suggest renaming TypeVarBoundBlock and TypeParamBlock but keep the three distinctions, at least for compatibility purposes. This change would affect the symtable module, especially symtable.SymbolTable.get_type but there are various issues with the current naming IMO.

1. FWIU, those blocks describe "annotation scopes". As mentioned here, class Bag[T] is equivalent to:

   annotation-def TYPE_PARAMS_OF_Bag():
     T = typing.TypeVar("T")
     class Bag(typing.Generic[T]):
         __type_params__ = (T,)
         ...
     return Bag
   Bag = TYPE_PARAMS_OF_Bag()

   In other words, upon encountering a generic class definition, we actually enter a TypeParamBlock. It is however very confusing to use that terminology because we are not processing a single type parameter, but possibly one or more type parameters.

2. Once we are in a TypeParamBlock, we then move to process the actual type parameters. Type parameters without bound/constraints/default have no symbol table and the TypeVarBoundBlock is used otherwise. However, since this kind of block is also used for non-typing.TypeVar objects but also for those typing.TypeVarTuple and typing.ParamSpec ones, this might be confusing. From what I remember on my compiler's & co lectures, in the following definition:

def foo[T: int, *Ts = *tuple[int], **P = [int, str]](): pass

I would say that T, *Ts and **P are "type variables" and that "foo" has 3 "type parameters". In particular, I would like to rename TypeParamBlock into TypeParamsBlock and TypeVarBoundBlock into TypeVarBlock even though it is implicitly assumed that there is a bound/constraints or default for that one. The rationale behind this choice is also motivated by the following test in test_symtable.py:

class GenericMine[T: int]:
  pass

The symbol table's type for GenericMine is "type parameter" (because it's the annotation scope); the symbol table's type for the inner's GenericMine (i.e., the concrete class being created) is "class" (this is fine) and the symbol table's type for "T" is "TypeVar bound", but this would also be its type if I had "[T = int]"...

The renaming would affect the current symtable module as follows:

• The corresponding constants would be renamed but we could perhaps keep the previous ones for compatibility purposes and deprecate them for 3.14.

• _symtable.TYPE_TYPE_VAR_BOUND should either refer to "type variable bound" only OR we add some additional information to know whether it is a type bound, a type constraint or a type default value. This information can also be used when considering a type alias but not when considering the type parameter. However, this requires to add three distinct booleans (two of them mutually exclusive but can be set both to 0) instead of the flags that I originally introduce. Otherwise, I don't know how to easily expose the different type of tables to symtable.

We could also emit a symbol table for type parameters without any bound, constraint or default and the renaming would make better sense. By the way, DEF_TYPE_PARAM is never exported to the Python module and we have something like:

>>> import symtable
>>> s = symtable.symtable("class A[T]: pass", "?", "exec")
>>> s.get_children()[0].lookup('T')
<symbol 'T': LOCAL, DEF_LOCAL>

where I would have expected T to be have the DEF_TYPE_PARAM flag. I'll open a separate issue for that one.

Thanks! I agree with renaming TypeParamBlock to TypeParamsBlock.

For TypeVarBoundBlock, note that it is used for bounds and constraints as well as defaults, and the latter can appear on ParamSpecs and TypeVarTuples as well as TypeVars. Therefore, I think it's better to use the full name "TypeVariableBlock", using "type variable" as a general term for all three flavors.

My biggest issue with changing these names is backwards compatibility in the symtable module. We explicitly document a set of strings at https://docs.python.org/3/library/symtable.html#symtable.SymbolTable.get_type. We can add to the set of strings for 3.14 and probably for 3.13, but for 3.12 it should stay the same.

Therefore, I think it's better to use the full name "TypeVariableBlock", using "type variable" as a general term for all three flavors.

Yes, that's what I had in mind (actually, I wrote TypeVarBlock but it should have been TypeVariableBlock, so my bad).

Since we are anyway using full names, I could also suggest using TypeParametersBlock, unless you think it's too verbose.

We can add to the set of strings for 3.14 and probably for 3.13, but for 3.12 it should stay the same.

3.13 should be fine (I guess) because it's still a pre-release so... but would it make sense to instead return enumeration constants that are publicly accessible instead of strings like that..? at least we wouldn't have the issue in the future if the grammar is extended/changed and we could probably make the attribute deprecated more easily ?

Yes, I think using an enum would make sense and it could be made backwards-compatible by using StrEnum.

@JelleZijlstra I've updated the proposal. By the way, I've only done that for what I've added but I'll likely re-order the case so that they match the enumeration. I put TypeAliasBlock, TypeParametersBlock and TypeVariableBlock in the enumeration (in that order) to reflect the "top-to-bottom" construction (TypeVariableBlock requires to first enter a TypeParametersBlock).

Thanks @picnixz for the PR, and @JelleZijlstra for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

Sorry, @picnixz and @JelleZijlstra, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 4bf17c381fb7b465f0f26aecb94a6c54cf9be2d3 3.13

I am doing the backport

GH-120641 is a backport of this pull request to the 3.13 branch.