PyPy is sold as the faster, alternative implementation of Python, but most developers only ever meet CPython. A practical walkthrough on betterprogramming.pub, building on a 2011 PyPy interpreter tutorial, puts the two side by side and shows what the toolchain actually demands.
The exercise is straightforward: write a small RPython program that generates prime numbers, run it under CPython, translate it through the PyPy toolchain, then compare runtimes using hyperfine. The result is a useful reality check on what "PyPy is fast" really means—and where the pitch breaks down.
Background: what is PyPy, really
Most people running python on the command line are running CPython, the default and most common implementation. PyPy is a separate project that uses a tracing JIT compiler and can be significantly faster on long-running, pure-Python workloads.
Under the hood, PyPy programs are written in RPython—a restricted subset of Python that the toolchain translates into a native binary. That translation step is what makes PyPy awkward to adopt. You are not just running a different interpreter; you are feeding your code through a build pipeline.
Our analysis
The walkthrough demonstrates that PyPy's speed advantage is real, but it does not arrive for free. You inherit a toolchain with Python 2.7-era path conventions, a translation step that takes tens of seconds even for a trivial program, and a learning curve steeper than "just install pypy3 and run your script."
The trade-offs are clear:
| Factor | CPython | PyPy |
|---|---|---|
| Setup complexity | Low | High (toolchain required) |
| Speed on pure Python | Baseline | Substantially faster |
| C extension support | Full | Limited |
| Modern Python version | Current | Patchy (2.7 workaround common) |
For a one-off data-science job, the overhead is not worth it. For a long-lived service doing heavy CPU work in pure Python, the calculus looks different—especially if you are already wrestling with a build pipeline.
The benchmarking approach is also worth borrowing. Hyperfine runs commands multiple times and reports statistical spreads, which helps separate genuine speedups from cold-start noise. The author wisely notes that hot vs. Cold starts, caching, and background processes all skew results. That kind of disclaimer is rare and welcome.
Decision checklist: should you try PyPy?
- Does your workload run for seconds or minutes, not milliseconds? → JIT warm-up only pays off with longer runs.
- Is your code pure Python, with no C extensions like NumPy? → PyPy's advantage evaporates with extensions.
- Can you tolerate a translation step in your build process? → You are adding a pipeline stage.
- Have you benchmarked a realistic workload with hyperfine? → Claims about speedups are workload-specific.
- Is your team comfortable maintaining 2.7-era workarounds if needed? → Python 3 toolchain support is still inconsistent.
If you answered yes to most of these, PyPy deserves a serious look. If not, CPython's simplicity wins.
What to watch next
Watch whether the PyPy project stabilises its Python 3 toolchain so the 2.7-era workarounds become unnecessary. Watch also for cleaner benchmarking patterns that handle warm-up and noisy cloud environments. Until then, treat PyPy as a serious option for the right workload, not a universal drop-in.
Key takeaways
- PyPy can beat CPython on pure-Python CPU-bound code, but the toolchain has rough edges.
- Hyperfine is a straightforward way to compare runtime across implementations.
- C extensions and modern Python versions are the usual blockers to adoption.
Frequently asked questions
Is PyPy faster than CPython?
Often, yes, on long-running, pure-Python workloads, thanks to its JIT. The article on betterprogramming.pub demonstrates this using hyperfine benchmarks.
What is RPython?
A restricted subset of Python that the PyPy translation toolchain can compile to a native binary.
Why does the article use Python 2.7.18?
The author encountered compatibility issues with newer Python versions when working through the PyPy translation toolchain.
Can I use PyPy with NumPy?
That is where things get complicated. PyPy's speedup applies mostly to pure Python; many C-extension-heavy stacks do not see meaningful benefits.