Summary
- Python 3.10 is now end-of-life and will no longer receive security patches — any production systems running it carry unmitigated risk going forward.
- Python 3.15 introduces a built-in sampling profiler (Tachyon) and explicit lazy imports, with practical implications for tooling performance and observability.
- Performance gains in 3.15 are modest over 3.14, though the experimental JIT compiler shows early promise with a measured 1.2x improvement on benchmark tests.
- Developers maintaining libraries across supported Python versions can now adopt 3.11 features, including significant SQLite and asyncio improvements.
- Organisations should audit pipelines and containerised workloads to identify any remaining 3.10 dependencies before exposure widens.
The End-of-Life Problem
Python 3.10, released in 2021, has formally reached end of life with the arrival of Python 3.15. That means no further security fixes from the Python core team. For security leaders, this is a concrete risk event, not a theoretical one. Any application, container image, or CI pipeline still running 3.10 is now accumulating unpatched exposure with each passing vulnerability disclosure. The question worth asking internally is not whether 3.10 is in use — it almost certainly is somewhere — but where and how quickly you can move away from it.
What 3.15 Actually Delivers
Python 3.15’s headline feature for developers is explicit lazy imports, standardised via PEP 810. Rather than loading a module at import time, the new syntax defers loading until the symbol is first used. The practical effect is faster startup for tools with heavy dependencies — developer Simon Willison notes this directly addresses multi-second startup delays in his LLM CLI tool caused by plugins loading large libraries at invocation. For security tooling authors and platform engineers shipping Python-based utilities, this is a meaningful quality-of-life improvement that may also reduce attack surface during initialisation sequences.
A Built-In Sampling Profiler
The more operationally interesting addition is Tachyon, a sampling profiler now included in the standard library as profiling.sampling. Unlike tracing profilers, sampling profilers work by periodically capturing stack traces from running processes — low overhead and no prior instrumentation required. Willison demonstrates attaching it to a running process by PID, producing reports, flame graphs, heat maps, and output compatible with the Firefox profiler UI. For teams doing incident response or performance triage on Python services, having this capability natively in the runtime — rather than relying on third-party tools — simplifies both toolchain governance and deployment policy.
Performance: Steady, Not Spectacular
Independent testing by Miguel Grinberg against the 3.15 release candidate found performance largely on par with 3.14. The exception is the experimental JIT compiler, which delivered a 1.2x improvement over the standard 3.15 interpreter on a Fibonacci benchmark — described as the first time a meaningful JIT gain was observed in this testing series. Grinberg’s 2024 testing of 3.14 found more significant gains over 3.13 across a broader range of categories. The JIT remains experimental, so production adoption should be evaluated carefully.
3.11 Features Now Fair Game
With 3.10 retired, maintainers of widely-used libraries can begin targeting 3.11 as their minimum supported version. For security teams that consume open source Python libraries, this transition matters: libraries dropping 3.10 support will accelerate over coming months, and any internal tooling pinned to 3.10 will increasingly find itself out of step with upstream dependencies. Python 3.11 itself introduced meaningful improvements, including TaskGroup and timeout() for asyncio, SQLite enhancements such as runtime limits and partial BLOB access, and the tomllib standard library module for TOML parsing without third-party dependencies.
Upgrading With uv
For teams using the uv package manager, Willison documents a straightforward upgrade path: update uv itself, install the 3.15 release, pin it as the global default, and reinstall any tool-installed packages against the new runtime. The commands are simple; the organisational work of identifying every environment that needs upgrading is not. That audit is the appropriate starting point.
Why it matters
End-of-life runtimes are a persistent and underappreciated source of unpatched vulnerability. Python 3.10 reaching EOL is not a future risk — it is a present one for any organisation that has not yet completed a full inventory of where Python 3.10 runs in production, CI, containers, and developer tooling. Security teams should treat this the same way they would treat an unsupported operating system: the clock has already started.
What to do now
- Conduct an inventory of all production systems, container images, and CI pipelines running Python 3.10 and prioritise their migration to a supported release.
- Evaluate Python 3.15 for non-production and tooling environments, particularly where startup performance or runtime observability are concerns.
- For teams using uv, follow the documented upgrade sequence: update uv itself before attempting to install or pin Python 3.15.
- Review internal Python libraries and tooling for any minimum version constraints still set to 3.10, and plan for upstream libraries to drop 3.10 support in the near term.
- Assess whether the experimental JIT in Python 3.15 is appropriate for production workloads before enabling it, given its early-stage status.
