TypeError: 'type' object is not subscriptable after python 3.9 upgrade

TypeError: 'type' object is not subscriptable after python 3.9 upgrade

TL;DR: Something subscripts a type (like list[int]) where the running interpreter evaluates it eagerly, and the interpreter actually executing the code is usually older than you think - or the subscripted name was never generic at all. Verify the real interpreter with python --version on the exact binary running the code, then fix the annotation or the class.

TypeError: 'type' object is not subscriptable after python 3.9 upgrade

Steps

1. Read the traceback and find the exact subscript expression that fails (often an annotation like x: list[int] or a custom class being subscripted). Expected: you have the failing line and the name being subscripted.

2. Check the real interpreter: run which python and then that binary with --version. Stale venvs, containers, and CI images often still run 3.8 while your shell says 3.9+. Expected: you confirm whether the executing interpreter is genuinely 3.9 or newer.

3. If it is older than 3.9: switch to the right interpreter, or rewrite with typing generics (List[int]) and add from __future__ import annotations for annotation-only usage. Expected: the TypeError goes away.

4. If it is 3.9+ and a builtin generic still fails, the name is shadowed by a non-generic import - inspect what it actually is. If it is your own class, add __class_getitem__ or inherit from typing.Generic. Expected: subscripting the class works.

Use this when

• The exact text 'type' object is not subscriptable appears after a Python upgrade.
• The failing code uses builtin generics (list[int], dict[str, int]) in annotations or at runtime.
• The traceback points at a class definition, dataclass field, or annotation being evaluated.

Not for this skill when

• The error is 'X' object is not subscriptable on an instance - that is an instance problem, not a type problem.
• The failing syntax is X | Y unions - those need Python 3.10+, different fix.
• A third-party class that was never generic is subscripted at runtime - that is a library usage error.

Variant phrasings

• type object is not subscriptable list int after upgrade
• python builtin generics not working 3.9
• subscriptable TypeError dataclass annotation

Why it happens

PEP 585 made builtin collections generic in Python 3.9, so on 3.9+ this error almost always means an older interpreter is actually running the code (the classic venv/container mismatch) - or the subscripted name is a plain class without __class_getitem__, which was never subscriptable on any version.

Edge cases

• from __future__ import annotations only defers annotation evaluation - runtime subscripts (casts, validators, explicit subscripts in function bodies) still fail on old interpreters.
• Dataclass and pydantic field types are evaluated eagerly, so they are the usual crash sites - check them first.
• Verify every interpreter in the chain (shell, venv, container, CI image) - fixing one while another runs the code changes nothing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5daLiyY4k9a-2Wr8ecH7CQ