I hear "Python is slow" the way I hear "a hammer is bad at making soup." Like... yes. Also, why are we doing this.
Someone told me last week that Python is too slow for their startup. I asked what they were building. A CRUD app that talks to Postgres. I hear "Python is slow" the way I hear "a Corolla isn't a rocket." True. Also, you bought the Corolla.
Most of the time, "Python is slow" is a meme people repeat because they heard it once in a comment thread, and now it lives rent-free in their brain. The real question is: slow at what, compared to what, and for which part of your program?
I'm going to do my favorite trick here: RTFM. Not because I'm a genius. Because reading the release notes tells you more than a Reddit thread from 2019.
"Python is slow" is a bad unit of measurement
If your Python app:
- waits on a database
- waits on the network
- waits on TLS handshakes
- waits on Redis
- waits on S3
- waits on some other computer you don't control
...then the Python interpreter is not your main problem.
I build a lot of boring-but-useful web stuff. Think Flask API, MariaDB, JSON responses, Docker, some HTML/JS/Tailwind glue. In that world, I can shave 25% off Python execution time and still lose to a single missing index in MySQL. You want "performance"? Add the index. Or stop doing N+1 queries. Or stop serializing a 5MB JSON blob because you were too lazy to page results.
Python traded speed for flexibility on purpose
Python is a general-purpose scripting language. It's simple. It's everywhere. It doesn't force you into a single framework or worldview.
That flexibility costs something. You get dynamic types, introspection, a friendly REPL, and a huge ecosystem. You don't get C-level speed for tight loops written in pure Python.
That trade is not a failure. That's what you signed up for.
CPython got a lot faster anyway (3.11 - 3.14)
Here's the part people miss: Python has been getting noticeably faster, and you often get the win with zero code changes.
Python 3.11 (Oct 2022): the big jump
Python 3.11 landed with something like 10–60% speedups depending on the workload, averaging around 25% faster than 3.10.
What changed:
- Specializing adaptive interpreter: it watches your code run and swaps generic operations for type-specific fast paths.
- Lazy heap allocations: it avoids creating certain debugging structures until needed.
- Inlined Python-to-Python calls: reduces overhead in function calls.
You upgrade Python. Your code runs faster. That's it. I'll take that deal.
Python 3.12 and 3.13: groundwork + experiments
3.12 gave us another ~5% and started the groundwork: per-interpreter GIL work, immortal objects. 3.13 added an experimental JIT and experimental free-threading. Also a much better REPL. The REPL improvements sound like fluff until you're staring at a typo at 2am and Python gently suggests you meant return instead of retrun.
Python 3.14 (Oct 2025): free-threading gets real
3.14 is 27% faster than 3.13 for some workloads, and free-threading is no longer a science project.
This is the headline: the GIL is now optional. For the first time in Python's history, you can run Python threads in true parallel on multiple cores in one process.
People blamed the GIL for everything. Slow API? GIL. Bad database queries? GIL. Marriage falling apart? Probably also the GIL.
The GIL mattered most for CPU-bound multithreaded Python bytecode. That's a narrower case than people think. Many apps are I/O-bound and don't care. For I/O-heavy workloads, Python asyncio recipes can help you handle concurrency without fighting the GIL.
But if you actually are CPU-bound and thread-heavy, free-threading matters. Benchmarks show major speedups (even multiple times faster) without rewriting your whole system into a multiprocessing hairball.
The Faster CPython project got funded... and then got corporate'd
The Faster CPython effort started around 2020. Mark Shannon wrote a plan to make CPython 5x faster. Guido van Rossum came out of retirement and joined Microsoft. This wasn't a weekend volunteer sprint. It was staffed and funded.
Then Microsoft killed the team in 2025.
I've been fired, laid off, quit, and ghosted by more companies than I care to remember. One place didn't even tell me. I just couldn't badge in one Monday. Each time it reminded me: companies are not families, and late-stage capitalism will not be inconvenienced with taking care of anyone.
The good news: the work is upstream in CPython. It doesn't vanish because a corporate org chart changed. And the improvements continue—Python 3.15's JIT compiler is taking the performance story even further.
Practical advice: stop chanting, start profiling
Python is a great choice if you're doing:
- Web APIs that spend time waiting on I/O
- Scripting and glue code
- ML workflows where the heavy math lives in optimized libraries (NumPy, PyTorch, etc.)
- Anything where you'd rather ship code than optimize loops
Python is not my first pick for:
- Embedded or real-time systems (microseconds matter)
- Mobile apps (you're living in iOS/Android land)
- Desktop games where raw speed is the whole business model
And if you're doing CPU-heavy work in pure Python? Upgrade. Python 3.11–3.14 are real improvements. Also, profile before you rewrite. Most "Python is slow" stories are actually "I wrote a quadratic loop and didn't notice."
I've wasted entire weeks chasing performance myths that turned out to be one missing database index. Profile first. Most of the time the problem is your code, not Python. And if it really is Python, upgrade to 3.14 before you rewrite everything in Rust. If you want to go deeper on optimization, AI-driven code optimization tools can help you measure, patch, and prove performance wins.
-Sethers
