The State of Python 2025: Trends and Survey Insights

### Most still use older Python versions despite benefits of newer releases The survey shows a distribution across the latest and older versions of the Python runtime. Many of us (15%) are running on the very latest released version of Python, but **more likely than not, we’re using a version a year old or older (83%)**. The survey also indicates that many of us are using Docker and containers to execute our code, which makes this 83% or higher number even more surprising. With containers, just pick the latest version of Python in the container. Since everything is isolated, you don’t need to worry about its interactions with the rest of the system, for example, Linux’s system Python. We should expect containerization to provide more flexibility and ease our transition towards the latest version of Python. … The 83% of developers running on older versions of Python may be missing out on much more than they realize. It’s not just that they are missing some language features, such as the `except` keyword, or a minor improvement to the standard library, such as `tomllib`. **Python 3.11, 3.12, and 3.13 all include major performance benefits**, and the upcoming 3.14 will include even more. What’s amazing is you get these benefits without changing your code. You simply choose a newer runtime, and your code runs faster. CPython has been extremely good at backward compatibility. There’s rarely significant effort involved in upgrading. Let’s look at some numbers. **48% of people are currently using Python 3.11. ** Upgrading to 3.13 will make their code run ~**11% faster** end to end while using ~**10-15% less memory**. If they are one of the 27% still on **3.10 or older**, their code gets **a whopping ~42% speed increase** (with no code changes), and **memory use can drop by ~20-30%**! So maybe they’ll still come back to “Well, it’s fast enough for us. We don’t have that much traffic, etc.”. But if they are like most medium to large businesses, this is an incredible waste of cloud compute expense (which also maps to environmental harm via spent energy). … ### Python web servers shift toward async and Rust-based tools It’s worth a brief mention that the production app servers hosting Python web apps and APIs are changing too. Anecdotally, I see two forces at play here: 1) The move to async frameworks necessitates app servers that support ASGI, not just WSGI and 2) Rust is becoming more and more central to the fast execution of Python code (we’ll dive into that shortly). The biggest loss in this space last year was the complete demise of uWSGI. We even did a *Python Bytes* podcast entitled *We Must Replace uWSGI With Something Else* examining this situation in detail. We also saw Gunicorn handling less of the async workload with async-native servers such as uvicorn and Hypercorn, which are able to operate independently. Newcomer servers, based on Rust, such as Granian, have gained a solid following as well. … Just last week, the steering council and core developers officially accepted this as a permanent part of the language and runtime. This will have far-reaching effects. Developers and data scientists will have to think more carefully about threaded code with locks, race conditions, and the performance benefits that come with it. Package maintainers, especially those with native code extensions, may have to rewrite some of their code to support free-threaded Python so they themselves do not enter race conditions and deadlocks.