@JelleZijlstra I found this issue based on the same assumption, that PEP 695 indicates a runtime-valid RHS of type parameters (even if not recursively expanded). AGeneric example:

typeGenericMetadata[T]=Annotated[T,list[T]]typeHardCodedMetadata=Annotated[int,list[int]]print(HardCodedMetadata.__value__)# Annotated[int, list[int]]print(GenericMetadata[int].__value__)# Annotated[T, list[T]] (not int??)

It seems this behavior violates theevaluatedvalue of the type alias statement in the PEP... Given TypeAlias is officiallydeprecated in favor oftype statements, what is the recommended alternative if__value__ support is not planned?

I don't know what to recommend to you because I don't know what you are trying to achieve. In general, I aim for the standard library to provide simple building blocks, and user code that knows what it wants can implement more complex operations (such as walking over a type and substituting type variables).

Thanks for the reply. My use case is to annotate IDs with information about what object they reference:

typeIdOf[T]=Annotated[UUID,T]

This can be hooked by e.g. JSON schema generators in pydantic models to provide more schema information/typing to endpoints accepting UUID strings.

As for how it relates totyping, my hope was that__value__ would supply runtime-specific generic values, as opposed to user-created custom traversals. The question was mostly about how to correctly interpret the PEP 695 spec if runtime type alias valuesaren't resolved within__value__

Tools interpreting such metadata should recognize GenericAlias instances wrapping TypeAliasType instances and resolve the TypeVar accordingly.