Python 3.11

Python 3.11 introduced substantial CPython runtime work, including an adaptive specializing interpreter, faster function calls, cheaper exception handling in common non-exception paths, and lazy creation of Python frame objects. The actual performance effect is workload-dependent and should be measured with the application's own benchmarks. It added ExceptionGroup and except* for handling failures from concurrent work, exception notes through add_note(), and more precise source locations in tracebacks. The standard library gained tomllib for reading TOML, asyncio.TaskGroup and asyncio.timeout for structured asynchronous concurrency, and regular-expression atomic groups and possessive quantifiers. Typing additions include Self, LiteralString, variadic generics, Required and NotRequired TypedDict items, and dataclass_transform.

Python 3.11 remains a supported line, so staying on it does not create an immediate unsupported-runtime problem. The main cost is foregoing runtime, language, standard-library, typing, diagnostic, and performance improvements delivered by later Python lines. That can matter most for CPU-bound services, tooling that relies on newer typing features, and projects whose dependencies begin to require a newer interpreter. Dependency support is the practical risk: a package may continue to install on 3.11 while withholding newer features or fixes from that interpreter, and eventually its maintained releases may raise their minimum Python version. Teams also accumulate migration work when they defer upgrades across several interpreter lines rather than validating each transition while dependency compatibility is current.

Keep 3.11 as an explicitly tested runtime while it remains part of the deployment estate, and confirm that production images, build systems, developer environments, and CI use the intended patch level. Inventory direct and transitive dependencies, including native extensions, and identify each package's supported Python range and wheel availability for the proposed target interpreter. Add the target interpreter to CI, run the full test suite with warnings enabled, and test packaging, type checking, asynchronous code, error handling, and traceback-sensitive assertions. Benchmark representative CPU-bound and latency-sensitive workloads rather than assuming a runtime improvement. Plan an incremental move to a later supported Python line, update CI and deployment artifacts first, then promote the new runtime through staging and production with rollback coverage. Use 3.11-specific features only where they improve the code today; avoid making compatibility assumptions that prevent the next interpreter upgrade.