Python 3.10 End of Life: 31 October 2026 — What Breaks and What to Do

Python 3.10 was released on 4 October 2021 and receives its last security fix on 31 October 2026 — five years and one month, which is the standard modern Python lifetime: roughly eighteen months of bugfix releases followed by three and a half years of security-only patches.

What actually stops on 31 October 2026

python.org stops publishing releases for the 3.10 branch. That is the whole of it. There is no kill switch, no telemetry, no warning banner. An application running on 3.10.21 on 1 November behaves exactly as it did on 31 October.

What ends is the patch supply. A vulnerability found in the interpreter, the standard library, or the bundled OpenSSL bindings after that date does not get a 3.10 fix from the core team.

There is one nuance worth understanding before you panic or relax, because it decides whether this date applies to you at all:

• If Python came from your distribution — apt install python3 on Ubuntu 22.04 LTS, for instance — that distribution patches the version it shipped for its own support window, which typically outlasts python.org's. Your interpreter keeps getting fixes.
• If Python came from anywhere else — pyenv, a python:3.10-slim base image, Homebrew, a compiled-from-source build, a CI action pinning python-version: "3.10" — nobody is patching it after this date. This is the common case and the one people miss.

What breaks if you stay

Not the interpreter. The ecosystem around it, and earlier than the date suggests.

Installs start failing before runtime does. Package maintainers raise their minimum Python on their own schedule. The moment a dependency you use ships a release with Requires-Python = ">=3.11", pip stops resolving:

ERROR: Ignored the following versions that require a different python version:
  4.0.0 Requires-Python >=3.11
ERROR: Could not find a version that satisfies the requirement somelib>=4.0

That error is the real deadline, and it arrives whenever your dependencies decide, not on 31 October. A pinned lockfile hides it until the first time you add or bump anything.

Base images disappear quietly. Official python:3.10 Docker tags stop receiving rebuilds, which means the OS layer underneath stops receiving its security updates too. The image still pulls. It is simply frozen, including its CVEs.

Compiled wheels stop being published. Projects with C extensions — numpy, pandas, cryptography, psycopg, pydantic-core — drop cp310 from their build matrices to shorten CI. When that happens, pip falls back to building from source, and you discover you need a full toolchain on a machine that has never needed one:

error: command 'gcc' failed: No such file or directory

Compliance tooling starts flagging it. pip-audit, Dependabot, Snyk and most SBOM scanners treat an unsupported runtime as a finding in its own right, independent of whether any specific CVE applies. If you ship to anyone who asks for a vulnerability report, this becomes someone else's problem to raise with you.

The one you are most likely to meet by name is Tenable's:

Python Unsupported Version Detection

That is a Nessus plugin, and it fires on the version, not on any particular vulnerability — so there is no patch that clears it and no argument to be had with the scanner. The finding stays open until the interpreter moves. Dependabot raises the same thing as an unsupported-runtime alert, and pip-audit reports it against the environment rather than a package. If a security team hands you a report with that line in it, this page is the explanation: nothing is exploitable yet, and nothing will be fixed either.

What the cloud providers do

python.org's date is not the only one that matters, and the managed platforms run their own clocks. This is where most teams actually get forced.

AWS Lambda ends support for the python3.10 runtime on 31 October 2026, the same day as python.org. The enforcement then arrives in two steps: from 1 February 2027 you can no longer create functions on that runtime, and from 3 March 2027 you can no longer update existing ones. Nothing stops being invoked — your functions keep serving traffic. You simply lose the ability to change them, which is a more awkward position than an outage: the first time you need a hotfix, the deploy is the thing that fails.

Managed databases and containers work the same way in shape if not in date: the provider publishes its own end-of-support, mails deprecation notices months ahead, and eventually force-upgrades or blocks changes. If you run Python on a managed platform, find that provider's date — it is the one that will interrupt you, and it is rarely the one on python.org.

The general rule: a runtime deprecation notice in your inbox is not the same event as an upstream end of life. Upstream stops shipping patches; the provider stops letting you deploy. Diary both.

The upgrade path: 3.10 → 3.13

Target 3.13. It was released in October 2024, is supported until 31 October 2029, and has had two years for compiled dependencies to settle. 3.11 only buys you until October 2027 — you would do this work twice. 3.14 is fine if your dependency set is pure Python, but it is under a year old and some wheels will still be missing.

If you were about to pick 3.12: it is the more common choice and it is not wrong, but it costs you the same migration. Everything that breaks between 3.10 and 3.12 — distutils, datetime.utcnow(), setuptools in fresh virtualenvs — breaks on the way to 3.13 as well. The only extra work is PEP 594's removed stdlib modules, and 3.13 buys a year more support for it.

Four things genuinely break in that jump. In rough order of how often they bite:

1. distutils is gone. Removed from the standard library in 3.12 under PEP 632.

ModuleNotFoundError: No module named 'distutils'

Most of the time this is not your code — it is an old setup.py, or a dependency that still imports it. Fix by moving to setuptools (which vendors a compatible distutils and provides setuptools._distutils), or better, by moving the project to pyproject.toml. Anything still calling distutils.spawn.find_executable should use shutil.which.

2. The "dead batteries" are gone. PEP 594 removed nineteen legacy stdlib modules in 3.13:

ModuleNotFoundError: No module named 'cgi'

The same applies to telnetlib, crypt, imghdr, nntplib, pipes, sndhdr, spwd, sunau, uu and xdrlib. Each has a documented replacement or a PyPI package carrying the old code forward. cgi is the one that catches people, usually via cgi.parse_header buried in an HTTP helper.

3. datetime.utcnow() is deprecated. Since 3.12:

DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled
for removal in a future version. Use timezone-aware objects to represent
datetimes in UTC: datetime.datetime.now(datetime.UTC).

Not fatal yet, but it will be, and the replacement is a one-line change per call site: datetime.now(timezone.utc).

4. setuptools no longer installs by default in new virtualenvs. Since 3.12, python -m venv does not include it. Anything that assumed import setuptools would work in a fresh environment now needs it declared explicitly in pyproject.toml's build-system.requires.

The cheapest way to find all four before you commit to anything:

python3.13 -W error::DeprecationWarning -m pytest

Run that against your existing suite on a 3.13 interpreter. Most of what you will fix is in dependencies rather than your own code, which makes the upgrade order obvious: bump dependencies first on 3.10, then move the interpreter.

If you can't upgrade yet

Some codebases genuinely cannot move by October — a vendored C extension with no maintainer, a certified environment, a dependency that pinned itself into a corner.

Move onto a distribution build. If your interpreter comes from Ubuntu 22.04 LTS or an equivalent long-support distribution, the distribution's security team keeps patching the 3.10 it shipped for its own window. Switching a container from python:3.10-slim to a distro base with the system Python is a smaller change than a version upgrade and buys real time.

Freeze deliberately, not accidentally. Pin your lockfile, pin the base image by digest rather than tag, and turn off automatic dependency updates for that service. A half-updated environment on an unsupported runtime is worse than a fully frozen one.

Write down the date you are deferring to, and put it somewhere that gets read. The most common failure here is not choosing to stay on 3.10 — it is staying on 3.10 without anyone deciding to.

Sources

• Python developer guide: status of Python versions — the authoritative support table
• PEP 632 — deprecating and removing distutils
• PEP 594 — removing dead batteries from the standard library
• endoflife.date: Python — the dates on this page, MIT licensed