Yesterday the Python team shipped 3.15.1 and 3.14.9. The release I actually care about this month is a different one: on October 1, 2026, Python 3.10 reached end of life. No more bugfix releases, no more security patches. 3.10.22 is the last one, forever.
I know this because the tool I use almost every day runs on it.
The tool
I built a small offline utility for myself that reads Swiss administrative letters - payment orders, reminders, official forms - and extracts the parts that matter: who wants money, how much, by when. It runs entirely on my laptop. Nothing leaves the machine, which is the whole point: these letters contain exactly the data you don't paste into a chatbot.
The constraint I gave myself was brutal and deliberate: Python standard library only. No pip install, no packages, no virtualenv. The result is about 306 lines of plain Python that I can drop onto any machine - including an old offline laptop - and run with whatever interpreter is already there.
That interpreter, on that machine, is Python 3.10.
Why I pinned myself to 3.10 in the first place
Choosing "stdlib only" sounds like a purist stance. It was actually an operational one. The machine that runs this tool is not always online, and I don't control when it gets updates. Every dependency is a supply chain you have to watch. Every pip install on an offline machine is a small ceremony. The standard library, on the other hand, is just there - same version as the interpreter, tested together, no network required.
The side effect I didn't fully think through: pinning to stdlib quietly pins you to the interpreter too. My code uses nothing newer than 3.10, so it runs everywhere from 3.10 up. But the machine itself still carries 3.10, and as of this month, that version gets nothing. Not even security fixes.
What end-of-life actually means here
Let me be precise, because "EOL" gets thrown around loosely. Python 3.10 entered security-only mode back in 2023, which means it has only received security patches since then. As of October 1, 2026, it receives nothing at all. If a vulnerability is found in the 3.10 interpreter tomorrow, there will be no official fix.
How much does that matter for my tool? Less than for a web service, more than zero. My threat model is narrow but real: the program parses files I didn't write - PDFs and scanned letters that arrive from outside. A maliciously crafted document attacking an unpatched interpreter bug is a theoretical attack path. For an offline single-user tool, it's a path I'm willing to walk for a few more weeks, not a path I want to live on.
The upgrade is cheap, and that's the payoff
Here's the part that makes me glad about the stdlib decision. Migrating a project off an EOL Python is usually painful because of dependencies: some package pins an old version, some C extension needs rebuilding, some transitive thing breaks. I have none of that. My entire dependency tree is the standard library, and the standard library's promise is backwards compatibility within reason.
So the plan is boring: install 3.15 on the machine, run the tool, run my handful of test letters through it, compare outputs. If 306 lines of stdlib Python don't survive a five-version jump, something has gone very wrong in the world. The release notes for 3.15 even work in my favor: UTF-8 is now the default encoding (PEP 686), which removes one of the few places where my file-reading code could behave differently across systems.
There's also one new 3.15 feature I'll genuinely use: explicit lazy imports (PEP 810). My tool starts, reads one letter, prints, exits. Startup time is most of its runtime. Lazy imports are made for exactly this shape of program.
The actual lesson
Dependencies are a bet. Every package you add is a bet that someone will keep maintaining it, that it will keep working with your Python version, and that you'll be online when you need to fix it. For this tool I bet on the standard library, and the bet paid off in an unexpected place: end-of-life day. When your Python version dies, the size of your problem is roughly the size of your dependency tree. Mine is zero packages, so my problem is an afternoon, not a project.
If you maintain anything still on 3.10 - and a lot of long-lived internal tools are - the clock that started on October 1 is real. The good news from yesterday's releases is that the landing spot is excellent. 3.15.1 is waiting.
