How do you use a typing feature your project's minimum Python lacks?

### The problem The type system moves faster than the runtimes people are still on. `typing.Self` and `typing.Never` arrived in 3.11, `typing.override` in 3.12, PEP 695 type-parameter syntax in 3.12. A library whose floor is older than those cannot simply import the name: the module would fail to import on the very runtimes it promises to support. Version skew is the gap between the typing vocabulary you want to write and the vocabulary your oldest supported interpreter can parse and bind. ### Route one: the back-port distribution The typing ecosystem ships a back-port distribution whose whole job is to make new `typing` names importable on older runtimes; where the running interpreter already has the name, it re-exports the standard-library object rather than a copy. Import from it unconditionally and the source has one import path, no branch, and nothing to keep in sync. Checkers understand it natively, because it is part of the typing specification's tooling story. The cost is an install-time dependency. Declare it in `pyproject.toml` like any other requirement, and gate it with a `python_version` environment marker if you want it installed only on runtimes that lack the name. Whether it needs to be a hard runtime dependency at all depends on where the name is used, which is the distinction below. ### Route two: a sys.version_info branch ```python import sys if sys.version_info >= (3, 11): from typing import Never else: from typing import NoReturn as Never ``` `sys.version_info` is a named tuple that compares element-wise against a tuple literal, so this is an ordinary runtime condition. What makes it useful for typing is that checkers evaluate the comparison statically: they are told which version to analyse for, resolve the condition themselves, and analyse only the branch that would be taken. That gives you one name with two provenances and correct analysis on every supported version. Checkers recognise a narrow set of forms — a comparison of `sys.version_info`, or of `sys.version_info[0]`, against a tuple or integer literal. Hide the version in a helper variable or a function call and the branch stops being statically resolvable, and the checker treats both sides as live or gives up. Keep the comparison literal and at module level. ### Route three: the checker-only import If the new name appears only inside annotations, neither dependency is needed. Guard the import with `TYPE_CHECKING` and keep the hint unevaluated. On 3.14 annotations are lazily evaluated by default (PEP 649), and on earlier runtimes the module carries `from __future__ import annotations` or quotes the hint. The checker gets the modern vocabulary and the shipped package gains nothing at all — no dependency, no branch. This route stops working the moment the name is evaluated at runtime: a decorator you actually apply, a runtime-checkable protocol used with `isinstance()`, a base class, an argument to a real call. Those need a genuine import, which means route one or two and a real dependency. ### What cannot be shimmed A back-port can supply a name; it cannot supply syntax. PEP 695 generics, the `X | Y` union operator outside a string on runtimes before 3.10, and any new grammar are parse-time features — an old interpreter raises `SyntaxError` before any conditional import runs, so no branch can save you. For syntax the choices are honest ones: raise the floor, write the older equivalent, or, for unions specifically, keep them inside annotations that are never evaluated. ### Declaring the floor All of this is downstream of one decision: what minimum version does the project support? Record it as `requires-python` in `pyproject.toml` so installers refuse the package on older interpreters instead of failing at import, run the checker against that floor rather than against whatever the developer has locally, and put every supported version in the CI matrix. A shim branch that is only ever taken on the oldest supported runtime is untested unless that runtime is in the matrix, and untested code that only the oldest users execute is the worst kind of untested. ### Choosing between the routes Default to the back-port when the name is needed at runtime, because one import path with no dead branch is cheaper to maintain than two. Use a version branch when you want to shed the dependency on newer runtimes or when the fallback is a local alias with no package behind it. Use the guarded import when the name lives only in annotations. And write down which route the project uses, because a codebase that mixes all three at random is one where nobody can tell which names are safe to call.