What object does Python's `type Point[T] = tuple[T, T]` statement create at runtime?

## A statement, not an assignment `type Point[T] = tuple[T, T]` looks like an assignment but is a distinct statement introduced in Python 3.12 (PEP 695). `type` here is a **soft keyword**: it is only special in this position, so the builtin `type` remains callable everywhere else and existing code named `type` keeps working. The statement binds `Point` to an instance of `typing.TypeAliasType`: ```python type Point[T] = tuple[T, T] print(type(Point)) # <class 'typing.TypeAliasType'> print(Point.__name__) # Point print(Point.__type_params__) # (T,) print(Point.__value__) # tuple[T, T] ``` Contrast that with the old style, `Point = tuple[float, float]`. A plain assignment binds an ordinary object — here a `types.GenericAlias` — and a checker has to *guess* from context that you meant an alias rather than a value. The `type` statement says so explicitly, and produces a distinct runtime object that tools can recognise. ## Laziness is the feature The expression on the right-hand side is not evaluated when the statement runs. The compiler stores it as a hidden zero-argument function; the first read of `__value__` calls it and caches the result. Two consequences follow, and both are the reason the feature exists. First, **forward and recursive references work without quotes**. A JSON-shaped alias can mention itself: ```python type Json = str | int | float | bool | None | list[Json] | dict[str, Json] ``` On a plain assignment that is a `NameError`, because `Json` is not bound yet when the right side runs. With the `type` statement the body runs later, by which time `Json` is bound to the alias object, so the self-reference resolves. Second, **the cost is deferred and paid once**. A module full of aliases does no work at import time, and an alias whose value is never inspected is never evaluated at all. The result is memoised on the alias object, so an expression with a side effect in it runs exactly once no matter how many times the value is read: ```python evaluations = [] def probe(t): evaluations.append(t) return t type Row = probe(dict[str, float]) print(evaluations) # [] - nothing has run yet Row.__value__ Row.__value__ print(len(evaluations)) # 1 - evaluated once, then cached ``` That is worth knowing precisely because the intuition cuts both ways. Someone who believes the body is eager will expect an import-time failure that never comes; someone who believes it re-runs per access will fear a repeated side effect that also never comes. ## Parameterizing and using an alias An alias declared with brackets is subscriptable. `Point[float]` produces a `types.GenericAlias` whose `__origin__` is the `TypeAliasType` and whose arguments are what you supplied; a checker substitutes them into the value. The alias itself is perfectly usable in annotations, unsubscripted, when it has no parameters. What it is *not* is a class. `isinstance(x, Point)` raises `TypeError: isinstance() arg 2 must be a type, a tuple of types, or a union`, and you cannot subclass an alias. Aliases name shapes for the type system; they do not create runtime types. Anyone who wants a genuinely distinct runtime-adjacent identity is reaching for a different tool. ## Where a lab-shaped example makes it concrete Consider a clinical-lab result loader with an alias `type Reading[T] = dict[str, T | None]`, where `None` marks an assay that did not report. Writing that shape once and referring to `Reading[float]` in a dozen signatures is exactly what aliases are for: the shape has one definition, and widening it — say, to allow a string-coded result — is one edit rather than a dozen. Because the value is lazy, the alias can sit at the top of the module and still refer to record classes defined further down. ## Version notes The `type` statement and `typing.TypeAliasType` are **3.12**. Type-parameter defaults on an alias (`type Table[K = str, V = float] = dict[K, V]`) are **3.13**. In **3.14**, annotations themselves became lazily evaluated by default under PEP 649, with `annotationlib` for inspecting them — which means the alias's laziness and the annotation system's laziness now line up rather than being two different models a reader has to hold at once. The older workaround for forward references, `from __future__ import annotations`, was never needed for the `type` statement in the first place: aliases were lazy from the day the statement shipped.