Python 3.10 dies in October. 3.14 is four hops away

Python 3.10 reaches end of life in October 2026. The Python developer guide's version status table lists the branch as security-only with a 2026-10 end date, and community discussion has settled on October 31, 2026 as the day. After that, no security patches follow, and the branch stops receiving fixes of any kind.

The upgrade target should be Python 3.14, which the same table supports until October 2030. The mistake is treating that as a version bump. A codebase sitting on 3.10 crosses 3.11, 3.12, 3.13 and 3.14 in one move, and the standard library it depends on shrank substantially along the way.

What happens when Python 3.10 reaches end of life?

Nothing breaks on the day. Python is the language and runtime maintained by the Python Software Foundation, and an end-of-life branch keeps running exactly as it did the week before. What ends is the patch supply. A vulnerability found in the interpreter or standard library after that date receives no upstream fix for 3.10.

Two groups feel this immediately. The first is anyone with a compliance obligation, since an unsupported runtime fails a security review whether or not a vulnerability exists yet. The second is anyone on a hosted platform, because platforms retire runtimes on their own schedule. Dynatrace, for example, has published its Python extension runtime update ahead of the deadline, which is how many teams discover they were still on 3.10 at all.

What breaks between Python 3.10 and Python 3.14?

The removals are concentrated in two releases, and they are the reason this is not a single hop.

Release	What it removes	Typical impact
3.11	Deprecations only, few removals	Low; mostly warnings that become errors later
3.12	distutils, asynchat, asyncore, imp, smtpd	High; build tooling and legacy async code
3.13	Nineteen PEP 594 modules, plus 2to3 and lib2to3	Medium; scripts and older libraries
3.14	Continued cleanups on top of the above	Low, if 3.12 and 3.13 were handled

PEP 632 is the proposal that scheduled the removal of the packaging module from the standard library. distutils is that module, removed in Python 3.12. The 3.12 release notes confirm that Setuptools continues to provide it for code that still needs it. A related change bites harder in practice: setuptools is no longer pre-installed in virtual environments created with venv, so distutils, setuptools, pkg_resources and easy_install are simply absent until you run pip install setuptools. Consider a build script that imports distutils.util inside a fresh CI container. On 3.10 it works. On 3.12 it fails with an import error, and the failure looks like a broken container rather than a language change.

Python 3.13 then removed nineteen modules deprecated under PEP 594, including cgi, telnetlib, crypt, nntplib, imghdr and pipes, according to the 3.13 removals list. It also removed 2to3 and lib2to3. Most of these have PyPI replacements such as standard-aifc and audioop-lts, so the fix is usually a dependency rather than a rewrite. The work is finding the imports, not repairing them.

How to sequence the upgrade

1. Run your test suite on Python 3.12 first, in a throwaway virtual environment, because that release carries the highest-impact removals.
2. Grep the codebase for distutils, imp, asyncore, asynchat and smtpd before you change anything, since those five explain most 3.12 failures.
3. Add pip install setuptools to any CI step that assumed a virtual environment would provide it.
4. Move to Python 3.13 next and grep for the PEP 594 module names, such as cgi and telnetlib, adding the PyPI replacements where they appear.
5. Land on Python 3.14 last and run the suite with warnings enabled, so deprecations due in later releases surface now.
6. Pin the runtime explicitly in your Dockerfile, CI config and hosting platform, using a 3.10 migration checklist as a cross-check, so a platform's retirement schedule cannot move it for you.

Step one saves the most time. Testing directly against 3.14 mixes four releases of failures into a single traceback pile, and separating them afterwards costs more than running the intermediate step.

Should you go to Python 3.14, or stop at 3.12?

Go to Python 3.14. The exact end-of-life day for 3.10 was debated on the Python discussion forum before settling in October, and the support window is the whole argument: 3.14 runs to October 2030, while 3.12 ends in October 2028 and 3.13 in October 2029. Stopping short saves a few days of work now and repeats the exercise in two years.

Stop at 3.12 only if a critical dependency has no 3.13 or 3.14 wheel and its maintainer has published no date. That is a real situation for some scientific and machine-learning stacks, and the honest response is to pin one service, record the exception, and move the rest of the estate.

Do not stay on 3.10 past October. The migration cost rises with every release you skip, because each one removes more of what your 2021-era code assumed was there. Readers who followed Python 3.15 hits rc1. Is free-threading ready yet? will notice the contrast: free-threading is an optional capability you can wait on, whereas an end-of-life branch is a date that arrives whether or not you are ready. The same distinction applies in Node.js 26 turns Temporal on. Upgrade now or wait?