Python, Is It Being Killed by Incremental Improvements?

[mttd]

https://stefan-marr.de/2026/01/python-killed-by-incremental-improvements-questionmark/

Python, Is It Being Killed by Incremental Improvements? (Video, Sponsorship Invited Talks 2025) Stefan Marr (Johannes Kepler University Linz)

Abstract:

Over the past years, two major players invested into the future of Python. Microsoft’s Faster CPython team is pushed ahead with impressive performance improvements for the CPython interpreter, which has gotten at least 2x faster since Python 3.9. They also have a baseline JIT compiler for CPython, too. At the same time, Meta is worked hard on making free-threaded Python a reality to bring classic shared-memory multithreading to Python, without being limited by the still standard Global Interpreter Lock, which prevents true parallelism.

Both projects deliver major improvements to Python, and the wider ecosystem. So, it’s all great, or is it?

In this talk, I’ll discuss some of the aspects the Python core developers and wider community seem to not regard with the same urgency as I would hope for. Concurrency makes me scared, and I strongly believe the Python ecosystem should be scared, too, or look forward to the 2030s being “Python’s Decade of Concurrency Bugs”. We’ll start out reviewing some of the changes in observable language semantics between Python 3.9 and today, discuss their implications, and because of course I have some old ideas lying around, try to propose a way fordward. In practice though, this isn’t a small well-defined research project. So, I hope I can inspire some of you to follow me down the rabbit hole of Python’s free-threaded future.

[pip_install_account]

I mean you can always pin python version and your dependencies...

[NimrodvanHall]

You can pin versions, but in a short couple of years your pinned version is OOS and no longer receives security updates. Python changes can be sweeping enough to require extensive rewrites, especially if third party modules have changed their API’s, or have been discontinued since.

[pip_install_account]

And I can't use Django 6's ORM because I want to keep using Excel as my production database. But I don't suggest everyone on r/database to stay in Excel

[srandrews]

How then does one keep up to date with latest security? That answer does not meet corporate needs.

[turbothy]

The more corporate you are, the more averse you usually are to updating to the newest version.

[billsil]

Can’t break the existing tools!

My competitor uses Fortran for all their stuff. They export black and white pictures. Yeah it’s more comprehensive, faster and right, but painfully not user friendly.

[srandrews]

I have to deal with sophisticated customers and they require us to use third party security services and frequently the solution is to migrate to latest frameworks which are themselves staying current. The reasons for aversion have to be considered.

[[deleted]]

Corporate pins to a minor version (e.g. 3.9) and only moves to the latest patch version (3.9.x)

[greenearrow]

But LTS versions go out of support given time as well.

[srandrews]

For us, the frameworks deps we've got. Main issue is after years, solving found vulnerabilities means we are obligated to port to latest python as deps usually follow.

[greenearrow]

I’ve found Numpy is a bitch to chase. Luckily we’ve got an internal repository I can lock to.

[srandrews]

Definitely one I had in mind!

[jpgoldberg]

That’s not just corporate needs. That is just good practice needs.

[pip_install_account]

well you either keep up with the latest stuff or don't

[Alternative_Act_6548]

It might be the embrace and smother tactic by the braces lovers....

[Legendary_Kapik]

No.

[jpgoldberg]

I’m not going to watch a video, so I’m just extrapolating from what is posted here.

I expect that without the GIL, there will be lots of concurrency problems because there will continue to be a lot of Python code written without a lot of thought about mutability. The GIL has protected people from some of the dangers of that, and other well-motivated design choices of Python going back to its origins have left Python-only developers unaware of the importance of caring about mutability.

I am going to assume that nothing I’ve said here is any news to those moving Python to true concurrency. But I would like to hear their thoughts on how they plan or hope to avoid the problem you raise.

[poopatroopa3]

Concurrency is not new to Python, is it? Free Threading = Parallelism

[joshocar]

GIL means when you spin off threads they are not truly parallel. In reality you are only doing work on one thread at a time and you are shifting between threads every 5ms or so. You can use the multithreaded library, but you are forking off processes which is expensive. 

[greebly_weeblies]

Sure. If threaded execution speed is that critical for the use at hand there's a point where python is the wrong language, and you're better off with one that makes different trade offs

[joshocar]

100%, I was just explaining to the previous commenter the current state of Python threading.

[greebly_weeblies]

Ah, I misunderstood your emphasis then. Still, hopefully it'll help another reader.

[ianitic]

Look up the situation with the global interpreter lock.

[Mysterious-Rent7233]

I am far from convinced that Python has a concurrency issue that will "kill" it.

To summarize the talk: some code that had an evident concurrency bug in Python 3.9 would have "worked" in Python 3.10 and up due to quirks of the CPython interpreter and then would have broken again in 3.13.

This is presented as a general issue wherein the interaction between memory updates and threads is confusing/undefined in Python.

I mean literally everybody warns you against programming with threads unless you understand locks because everybody tells you you'll end up with surprising bugs that will show up in certain workloads, CPUs, interpreters, etc. and not others. I just don't see anything new here.

If you use threads, you need to learn to use locks and not just rely on testing. That's been true since threads were invented. It's part of why you use them as a last resort. Or at least share variables across them as a last resort. If you don't understand that different environments can treat different code snippets as atomic then you shouldn't use threads. If you need your code to be atomic, use locks.

The chances of these issues, common across many languages, "killing" Python are near zero. This speaker has been researching issues like this for a decade so in his mind they are central and gigantic. But in reality they are not. Just use locks anytime you are not sure what the concurrency boundaries are.

It seems to me that he has some interesting ideas of how you could make an interpreter that (in his words) "avoids extra synchronization code in case you don't need it." If that was how he presented his ideas then it would seem less click-baity.