What does the `= int` do in Python's `class Box[T = int]` declaration?

## The feature Python 3.13 added PEP 696, type-parameter defaults, on top of the 3.12 bracket syntax. A default is written with `=` inside the parameter list: ```python class Box[T = int]: def __init__(self, item: T) -> None: self.item = item ``` To a type checker, an annotation that says just `Box` now means `Box[int]`. Without a default, a bare `Box` is an incompletely parameterized generic, and checkers treat that as implicitly `Box[Any]` or flag it, depending on strictness settings. A default turns "unspecified" into a deliberate, documented choice. The same syntax works in all three places the bracket list appears: ```python def collect[T = str](values: list[T]) -> set[T]: ... class Box[T = int]: ... type Table[K = str, V = float] = dict[K, V] ``` ## Where it earns its keep The motivating case is a generic that is *usually* used at one type. In a clinical-lab result loader, a container of assay results is nearly always keyed by assay code and valued by a float measurement; the rare case carries a string-coded result instead. Writing `type Panel[V = float] = dict[str, V | None]` lets most of the codebase say `Panel` and the outlier say `Panel[str]`, instead of forcing every one of a hundred annotations to repeat the common case. It is a readability feature, and its cost is that a reader must know the default exists — which is why keeping the default obvious and boring matters more than saving keystrokes. ## The ordering rule One constraint applies: **a parameter without a default may not follow one with a default**, exactly as for function arguments. Unlike most typing mistakes, this one is caught by the parser: ```python try: exec("class Box[T = int, U]: ...") except SyntaxError as exc: print(exc) # non-default type parameter 'U' follows default type parameter ``` That it is a `SyntaxError` rather than a checker diagnostic is the memorable detail: the file will not import, with or without a type checker in the loop. ## Runtime introspection Defaults are visible on the `typing.TypeVar` objects the brackets create: ```python import typing class Box[T = int]: ... (tv,) = Box.__type_params__ print(tv.has_default()) # True print(tv.__default__) # <class 'int'> def g[U](x: U) -> U: ... (uv,) = g.__type_params__ print(uv.has_default()) # False print(uv.__default__ is typing.NoDefault) # True ``` `has_default()` and the `typing.NoDefault` sentinel are both 3.13 additions. The sentinel exists because `None` is itself a legitimate default — a parameter really can default to `None` — so a falsy return could not distinguish "defaults to None" from "has no default". Prefer the `has_default()` predicate in introspection code; it says what you mean. As with everything else in the bracket syntax, nothing happens at call time. Constructing `Box(3.5)` does not check or coerce anything, and the default does not make the instance "a `Box[int]`" in any runtime sense. The default is a statement to the type system, plus a runtime-inspectable record of that statement. ## The pre-bracket spelling The same capability landed on the old API in 3.13: `TypeVar("T", default=int)`. That matters for libraries that still support Python 3.12 or earlier runtimes and therefore cannot use the bracket syntax at all — though on 3.12 the `default=` keyword itself is unavailable, so a truly wide-support library reaches for the backported typing extensions distribution instead of the stdlib. On a codebase whose floor is already 3.13, the bracket form is the one to write. ## Versions, stated exactly Bracket type parameters: **3.12**. Type-parameter defaults, `has_default()` and `typing.NoDefault`: **3.13**. Nothing in this area changed in **3.14**, whose typing news was elsewhere — deferred annotation evaluation under PEP 649 and the `annotationlib` module. If asked to date the feature, the trap is answering "3.12, with the rest of PEP 695"; defaults are a separate PEP that shipped one release later.