Python 3.10 End of Life: Your Upgrade Plan

Python 3.10 end of life was October 1, 2026, yesterday as I write this. Python 3.10.22 was the final security release, and the 3.10 codebase is now frozen. Any CVE found in the interpreter from here on stays unpatched for 3.10.

If you run Python on AWS Lambda, you have one more date to care about: the `python3.10` runtime is deprecated on October 31, 2026. So the window to plan this calmly is roughly four weeks.

Key Takeaways

• Python 3.10 reached end of life on October 1, 2026, per the Python devguide; 3.10.22 was the last release.
• Upgrade to 3.12 or 3.13 for most production code. Both are in security-fix mode until October 2028 and October 2029.
• The changes that break real code are removals: `distutils`, `imp`, `asyncore`, and 19 "dead battery" modules in 3.13.
• A typical Django or FastAPI service upgrade is one to two engineer-weeks; most of the time goes into dependencies, not your own code.

Python 3.10 End of Life and the Versions That Replace It

Here is where every branch stands today, from the devguide and the AWS Lambda runtimes page:

My default recommendation is 3.12 or 3.13. 3.11 buys you only one year. 3.14 is the newest stable line and fine for greenfield, but some compiled packages lag the newest release by a few months, so check your heaviest dependencies (numpy, pandas, psycopg, anything with C extensions) before picking it.

One more Lambda detail: `python3.10` runs on Amazon Linux 2, and AWS notes that Amazon Linux 2 itself was scheduled for end of life on June 30, 2026. `python3.12` and later run on Amazon Linux 2023. On Lambda, deprecation does not stop existing functions. Creating new `python3.10` functions is blocked from July 29, 2027 and updates from August 31, 2027.

What Breaks Between 3.10 and 3.12 or 3.13

Python minor upgrades are usually gentle. These two are less gentle than most, because they finish removals that were announced years ago. From the official What's New in 3.12 and What's New in 3.13:

• `distutils` is gone in 3.12. Old `setup.py` files and build scripts that import it fail.
• `imp`, `asyncore` and `asynchat` are removed in 3.12. Older libraries (and some internal scripts) still import them.
• venv no longer pre-installs setuptools in 3.12. CI scripts that assumed it was there break in a confusing way.
• Invalid escape sequences like `"\d"` in a normal string now raise `SyntaxWarning`. Harmless, but your logs fill up and strict CI setups may fail.
• 19 modules removed in 3.13 under PEP 594, including `cgi`, `crypt`, `imghdr`, `telnetlib` and `pipes`. `lib2to3` is gone too.

The pattern I see over and over: your code is fine, and a transitive dependency pinned three years ago is what breaks.

The Upgrade Plan That Works

1. Inventory runtimes. Containers, Lambda functions, CI images, cron boxes, data notebooks. Teams usually find one or two forgotten 3.9 or 3.10 jobs.

2. Upgrade dependencies first, on 3.10. Bump to versions that support both 3.10 and your target. This splits "dependency breakage" from "interpreter breakage".

3. Run the test suite on the target version in CI, in parallel with 3.10, and fix what fails.

4. Switch base images and Lambda runtimes, deploy to staging, watch error rates for a few days.

5. Roll out per service, starting with the least critical one.

A Concrete Version

A Series A company runs a Django monolith (about 80,000 lines), three FastAPI services, six Lambda functions on `python3.10`, and a Celery worker. Test coverage is around 60%. Target: Python 3.12.

• Dependency audit and bumps on 3.10, including a Django minor upgrade: 4 days.
• Fix `distutils` and `imp` imports in two internal packages, fix venv/setuptools assumptions in CI: 2 days.
• Test fixes on 3.12 across the monolith and services: 3 days.
• Move six Lambdas to `python3.12`, redeploy, smoke test: 1 day.
• Staging soak and staged rollout: 2 days.

That is 12 engineer-days. One engineer, two and a half weeks. That fits before October 31 only if someone starts this week and does nothing else. In practice, nobody on a product team does nothing else, which is why this kind of job often slips into Q1.

The Honest Counterpoint

You do not need to panic about every 3.10 process. The interpreter is end of life, but most real-world vulnerabilities live in your dependencies and frameworks, which keep shipping fixes for a while. An internal batch job with no network input is low risk for a few months.

There are two cases where I would not wait. Anything on Lambda, because the AWS clock is separate and the update block in August 2027 will arrive during some busy week. And anything public-facing that parses user input. For those, treat October 31 as the real deadline.

If the upgrade keeps losing to roadmap work, that is a capacity problem, and it is the same one behind most unpaid technical debt. A senior Python engineer can own the upgrade end to end while your team ships features. If you are mid-way through a larger cleanup, see how to hire developers to modernize a legacy app. Running Node too? The Node 20 end of life already passed in April.

Frequently Asked Questions

When is Python 3.10 end of life?

October 1, 2026. The final release was 3.10.22, and the branch receives no further fixes.

Should I upgrade from Python 3.10 to 3.11, 3.12 or 3.13?

3.12 or 3.13. 3.11 reaches end of life in October 2027, so you would repeat this work in a year. 3.12 runs until October 2028 and 3.13 until October 2029.

What happens to AWS Lambda functions on python3.10?

AWS deprecates the `python3.10` runtime on October 31, 2026. Functions keep running, but new function creation is blocked from July 29, 2027 and updates from August 31, 2027.

The Bottom Line

Python 3.10 is done. For a typical service the work is one to two engineer-weeks, mostly dependency cleanup, and the Lambda deadline is four weeks out. If your team cannot absorb it, request a shortlist of senior Python engineers and get it off the board.

Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers, with a vetted shortlist in 72 hours. See available engineers.