On this page · 10 sections
- What is supported, and what only looks supported
- Why teams are behind, in their own words
- Free-threading is officially supported, and that is a skills question
- The Lambda dates, and the Amazon Linux 2 problem underneath them
- What to actually test for
- Engagement models
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. Python 3.10 reaches end of life in October 2026, about six weeks from now. It has been source-only since 3.10.11 on 5 April 2023, which the release schedule marks as the "final regular bugfix release with binary installers", and its most recent security patch was 3.10.20 on 3 March 2026. Python 3.9 already died on 31 October 2025. Only two versions, 3.13 and 3.14, are in bugfix status today; 3.11 and 3.12 are security-only, with 3.12 running to October 2028 and 3.11 to October 2027. The current stable release is Python 3.14.7, shipped 5 August 2026 with around 499 bugfixes from 86 contributors. In the most recent published Python Developers Survey, 15% of respondents were still mostly on 3.10 and 6% on 3.9. And AWS blocks updates to python3.10 Lambda functions from 3 March 2027. If you are about to hire Python developers, those dates are the job description.
What is supported, and what only looks supported
The Python developer guide's version table is the authority here, and its status labels carry more weight than most teams realise. A security status means "only security fixes are accepted and no more binaries are released". That is not a soft warning. It means no Windows or macOS installers, source-only patches at irregular intervals, and nothing else.
| Python version | Status on 18 Aug 2026 | End of life |
|---|---|---|
| 3.9 | End of life | 31 Oct 2025 |
| 3.10 | Security-only, source releases | Oct 2026 |
| 3.11 | Security-only, source releases | Oct 2027 |
| 3.12 | Security-only, source releases | Oct 2028 |
| 3.13 | Bugfix | Oct 2029 |
| 3.14 | Bugfix, current stable 3.14.7 | Oct 2030 |
| 3.15 | Prerelease, first release 1 Oct 2026 | Oct 2031 |
Python 3.12 illustrates the trap. It shipped a security release, 3.12.14, on 12 August 2026 covering four CVEs, including CVE-2026-2297 (SourcelessFileLoader not using io.open_code() when opening .pyc files) and CVE-2026-4224 (an xml.parsers.expat crash from unbounded C recursion on deeply nested XML content models). The release page also states that "Python 3.12.10 was the last full bugfix release of Python 3.12 with binary installers". So a team on 3.12 is patched, but it is building from source or relying on a distribution to do so, and it will not receive a non-security fix again.
Python 3.15 is on schedule for 1 October 2026, with Hugo van Kemenade as release manager, following the 17-month development period and 12-month cadence set out in PEP 602. The practical consequence is that the moment 3.15 ships, 3.10 leaves and the supported set moves up by one. We covered what 3.15 brings in our Python 3.15 upgrade guide.
Why teams are behind, in their own words
The most recent published Python Developers Survey, the eighth annual edition run jointly by the Python Software Foundation and JetBrains PyCharm, collected responses in October and November 2024 from more than 30,000 developers across almost 200 countries, with more than 25,000 surviving filtering. There is a ninth edition fielded in 2026, but its results are not published, so this remains the honest figure to quote.
Version adoption at that point: 3.12 at 35%, 3.11 at 21%, 3.13 at 15%, 3.10 at 15%, 3.9 at 6%. Separately, 4% of respondents were still using Python 2.
The more useful data is why. Asked why they had not upgraded, 53% said "the version I'm using meets all my needs", 27% said "my projects are not compatible with the latest Python version", 25% said "I haven't had the time to update", 17% cited stability concerns and 12% said organisational policy fixed the version. Only one of those five is a technical blocker. The rest are a scheduling problem, which is precisely what a contract engagement can fix and a feature-only engagement will not.
The stack around Python moved faster than Python itself. Web framework use in 2024 was FastAPI 38%, Django 35%, Flask 34%, with FastAPI climbing from 21% in 2021. PostgreSQL leads databases at 49%, SQLite 37%, MySQL 31%. On packaging, pip is at 74% but uv reached 11% for environments and 12% for dependency management in its first year in the survey, and 33% of respondents writing binary modules use Rust, up from 27%.
That matters for who you hire. Seth Larson, Security Developer-in-Residence at the PSF, put the supply-chain case directly: "The adoption of dependency management tools that support locking dependencies to checksums and versions is great to see from a supply-chain security perspective. All applications in Python should be using one of these tools, such as pip-tools, Poetry, or uv." A candidate who cannot explain a lockfile is not a 2026 Python hire.
Free-threading is officially supported, and that is a skills question
This is the change most likely to be misdescribed in an interview. PEP 703, "Making the Global Interpreter Lock Optional in CPython", is Final and targeted Python 3.13, where the free-threaded build shipped as explicitly experimental. PEP 779, "Criteria for supported status for free-threaded Python", is also Final, resolved on 16 June 2025, and it is the one that moved free-threading to phase II. Python 3.14 ships it as officially supported, confirmed on the 3.14.7 release page: "PEP 779: Free-threaded Python is officially supported".
Phase III, making it the default, has not happened. PEP 779 says that decision "is left for a future PEP". Anyone telling you the GIL is gone in 2026 is a version and a phase ahead of reality.
The costs are published, which makes them a fair interview topic. PEP 779 records the single-threaded penalty as "currently around 10% (except on macOS, where it's more like 3%)" and memory as "about 15-20% higher", against accepted phase-II targets of 15% for CPU and 20% for memory. So free-threading buys parallelism on multi-core workloads at a measurable cost to everything else. Ask a candidate when that trade is worth taking. The right answer is narrow: CPU-bound work that is currently paying for multiprocessing, not a Django request path.
The Lambda dates, and the Amazon Linux 2 problem underneath them
AWS runtime deprecation is where the Python version question stops being theoretical.
| Lambda runtime | OS | Deprecation | Block create | Block update |
|---|---|---|---|---|
python3.9 |
Amazon Linux 2 | 15 Dec 2025 | 1 Feb 2027 | 3 Mar 2027 |
python3.10 |
Amazon Linux 2 | 31 Oct 2026 | 1 Feb 2027 | 3 Mar 2027 |
python3.11 |
Amazon Linux 2 | 30 Jun 2027 | 31 Jul 2027 | 31 Aug 2027 |
python3.12 |
Amazon Linux 2023 | 31 Oct 2028 | 30 Nov 2028 | 10 Jan 2029 |
python3.13 |
Amazon Linux 2023 | 30 Jun 2029 | 31 Jul 2029 | 31 Aug 2029 |
Two details are worth pulling out. The python3.10 block dates are not the standard 30 and 60 days after deprecation; AWS states it is "delaying the block-function-create and block-function-update dates beyond the usual 30 and 60 days after deprecation" for some runtimes. And the whole 3.9, 3.10 and 3.11 group sits on Amazon Linux 2, which AWS says "is scheduled for end of life on June 30, 2026". The base OS died before the runtimes did.
python3.15 is listed as a public-preview runtime with a November 2026 target, and AWS describes preview runtimes as "not covered by the Lambda SLA or Technical Support" and unsuitable for production. So the practical landing zone for new work today is python3.13 or python3.14, both on Amazon Linux 2023.
What to actually test for
Python interviews still overwhelmingly test syntax, which is the least scarce thing on the market. The survey found that 31% of respondents had under a year of professional experience and 19% had one to two years, so half the pool is early-career. Screening for depth matters more than screening for language familiarity.
Useful questions, all answerable in conversation:
- What is the difference between a
securityand abugfixPython version, and what stops shipping at the boundary? (No binary installers.)
- What does free-threaded Python cost on single-threaded work, and when is that trade worth it?
- Which lockfile does your project use, and what does it pin: versions, checksums, or both?
- Your Lambda runs
python3.10. What is the deadline, and what actually breaks first?
- You are on 3.12 and a dependency drops support. Do you upgrade Python or pin the dependency, and why?
The point of each is the same: production Python is a versioning and packaging discipline, and the code is the easy part.
Engagement models
This page sits alongside our Python development company page deliberately. That one is about project delivery. This one is about who owns the interpreter version.
| Model | Fits when | Fails when |
|---|---|---|
| Dedicated Python engineers, monthly | You own the roadmap and need capacity plus version ownership | The need is one fixed deliverable with an end date |
| Embedded pod with a tech lead | No senior Python voice in-house; packaging standards need setting | You already have a strong lead and need only hands |
| Capped migration engagement | Known shape, such as 3.10 to 3.13 across services before Feb 2027 | Requirements are still being discovered |
| Upgrade and dependency retainer | Keeping services on a bugfix-status version year after year | Nothing ships and nothing needs patching |
| Fixed scope | Well-specified service with pinned dependencies and a frozen interface | The interpreter moves under you mid-build |
For most teams the honest answer is a capped migration now and a small retainer afterwards. Moving one service from 3.10 to 3.13 is measured in days when scheduled and in weeks when it collides with an AWS block date.
India-specific considerations
Indian teams carry the same October 2026 deadline with an extra constraint: the Digital Personal Data Protection Act 2023 makes breach handling a statutory obligation, and two of the four CVEs fixed in Python 3.12.14 on 12 August 2026 sit in parsing paths that touch untrusted input, including the xml.parsers.expat recursion crash and a http.cookies.Morsel control-character issue. Running a source-only interpreter branch on production systems handling personal data is a defensible choice only if someone is actually rebuilding it.
The cheapest structure is usually not headcount. It is a named owner for interpreter versions and dependency locks, delivered either in-house, through staff augmentation services, or as a dedicated offshore product engineering team. The survey figure that should worry a CTO is not the 15% on 3.10. It is the 25% who said they simply had not had time.
FAQ
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. On Python work we take the parts that slip: moving services off 3.10 and 3.11 before the AWS block dates, replacing loose requirements files with checksum-pinned locks, and testing whether free-threaded builds are worth it for a specific workload rather than assuming they are. We staff that as embedded engineers or as a capped migration, and we will tell you which one fits. Talk to us at /contact-us/.
References
- Status of Python versions - Python Developer's Guide
- Python 3.14.7 release - Python Software Foundation, 5 August 2026
- Python 3.12.14 security release - Python Software Foundation, 12 August 2026
- Python source releases - Python Software Foundation
- PEP 619 - Python 3.10 Release Schedule - Pablo Galindo Salgado
- PEP 790 - Python 3.15 Release Schedule - Hugo van Kemenade
- PEP 779 - Criteria for supported status for free-threaded Python - Thomas Wouters, Matt Page, Sam Gross
- Python Developers Survey 2024 Results - Python Software Foundation and JetBrains
- Your Python, Your Voice: Join the Python Developers Survey - Marie Nordin, PSF, 26 January 2026
- Lambda runtimes - AWS Lambda Developer Guide
Last updated: 18 August 2026.