Why does `isinstance(x, list[int])` raise TypeError at runtime?

### What the subscript actually builds `list[int]` is an ordinary expression, evaluated when it runs. It calls the class-level subscript hook that PEP 585 added in **Python 3.9** and produces a `types.GenericAlias`: a lightweight object remembering the origin class (`list`) and the parameters (`int`). It is cheap, it compares equal to another `list[int]`, and its `repr` is `list[int]`. What it is *not* is a class — it is a description of one. ### Why isinstance refuses it Give that object to `isinstance` and CPython raises immediately: ```pycon >>> isinstance([1, 2], list[int]) Traceback (most recent call last): ... TypeError: isinstance() argument 2 cannot be a parameterized generic ``` `issubclass` behaves the same. The refusal is deliberate rather than a missing feature, and the reasons stack up: **It could not be answered honestly.** Is `[]` a `list[int]`? Every empty list matches every element type, so the answer is yes for `list[str]` too — a check whose result does not distinguish the thing being asked about. **It would break the cost model.** `isinstance` is expected to be a cheap constant-time class test. Verifying `list[int]` means visiting every element, so a check against a 6,800-row batch would traverse 6,800 objects behind a call that looks like a type test. Nested types make it worse: `dict[str, list[tuple[str, int]]]` would recurse through the whole structure. **It is sometimes impossible.** For containers that produce values on demand there is nothing to inspect without consuming the source, which the check has no right to do. **And it would still not be a type check.** Nothing stops a caller appending a `str` to a list that passed a moment ago. Static typing reasons about how a value is used across the program; a runtime snapshot cannot. ### What does work at runtime The container class alone is checkable, and so are several nearby things people conflate with the parameterised case: * `isinstance(x, list)` — fine, the plain class. * `isinstance(x, collections.abc.Mapping)` — fine. Unparameterised ABCs answer through a subclass hook, which is how a `ChainMap` or a `MappingProxyType` reports as a `Mapping`. * `isinstance(x, collections.abc.Sequence[str])` — `TypeError`, exactly like `list[int]`; parameterising is what breaks it, not the module it came from. * `isinstance(x, int | str)` — fine since **Python 3.10**, because a union of plain classes is a set of classes with nothing to walk. So the practical pattern is to check the shape and then validate the contents yourself when you actually need the guarantee: ```python def as_counts(value: object) -> list[int]: if not isinstance(value, list): raise TypeError("expected a list") if not all(isinstance(item, int) for item in value): raise TypeError("expected a list of ints") return value ``` That is explicit about its cost — the `all(...)` really does touch every element — which is precisely the honesty `isinstance` declines to fake. ### The bigger point: annotations are never enforced The `TypeError` is a specific symptom of a general fact. CPython does not check annotations at all. A function declared `-> dict[str, int]` may return a list; a parameter annotated `int` may receive a str. Even the generic alias itself is happy to be used as a constructor and checks nothing: ```pycon >>> list[int]([1, "two"]) [1, 'two'] ``` The alias forwards the call to its origin class and hands back a perfectly ordinary list. On **Python 3.14** the annotations are not even evaluated at definition time: PEP 649/749 made them lazy, so `def pick(rows: list[NotDefinedYet]) -> None: pass` defines without error and the `NameError` surfaces only when something reads the annotations. Verification is the job of a static checker before the code runs, or of an explicit validation step written into the code — a hand-rolled guard, a dataclass with your own validation step, or a runtime data-validation library, all of which pay the traversal cost openly. ### Answering it well in an interview Name the object (`types.GenericAlias`), name the error, and give the reason in terms of what the check would have to do: walk the container, get the empty case wrong, and still not mean what static typing means. Then show the fallback — class test plus explicit element validation — and the contrast cases that *do* work, `isinstance(x, list)` and `isinstance(x, int | str)`. Candidates who instead say "type hints are checked at runtime" reveal the misconception the question exists to find.