I was looking at PyPy and I was just wondering why it hasn’t been adopted into the mainline Python distributions. Wouldn’t things like JIT compilation and lower memory footprint greatly improve the speeds of all Python code?
In short, what are the main drawbacks of PyPy that cause it to remain a separate project?
Advertisement
Answer
PyPy is not a fork of CPython, so it could never be merged directly into CPython.
Theoretically the Python community could universally adopt PyPy, PyPy could be made the reference implementation, and CPython could be discontinued. However, PyPy has its own weaknesses:
- CPython is easy to integrate with Python modules written in C, which is traditionally the way Python applications have handled CPU-intensive tasks (see for instance the SciPy project).
- The PyPy JIT compilation step itself costs CPU time — it’s only through repeated running of compiled code that it becomes faster overall. This means startup times can be higher, and therefore PyPy isn’t necessarily as efficient for running glue code or trivial scripts.
- PyPy and CPython behavior is not identical in all respects, especially when it comes to “implementation details” (behavior that is not specified by the language but is still important at a practical level).
- CPython runs on more architectures than PyPy and has been successfully adapted to run in embedded architectures in ways that may be impractical for PyPy.
- CPython’s reference counting scheme for memory management arguably has more predictable performance impacts than PyPy’s various GC systems, although this isn’t necessarily true of all “pure GC” strategies.
- PyPy does not yet fully support Python 3.x, although that is an active work item.
PyPy is a great project, but runtime speed on CPU-intensive tasks isn’t everything, and in many applications it’s the least of many concerns. For instance, Django can run on PyPy and that makes templating faster, but CPython’s database drivers are faster than PyPy’s; in the end, which implementation is more efficient depends on where the bottleneck in a given application is.
Another example: you’d think PyPy would be great for games, but most GC strategies like those used in PyPy cause noticeable jitter. For CPython, most of the CPU-intensive game stuff is offloaded to the PyGame library, which PyPy can’t take advantage of since PyGame is primarily implemented as a C extension (though see: pygame-cffi). I still think PyPy can be a great platform for games, but I’ve never seen it actually used.
PyPy and CPython have radically different approaches to fundamental design questions and make different tradeoffs, so neither one is “better” than the other in every case.