What is PyPy?
PyPy is a replacement for CPython. It is built using the RPython language that was co-developed with it. The main reason to use it instead of CPython is speed: it runs generally faster (see next section).
PyPy 2.5 implements Python 2.7.8 and runs on Intel x86 (IA-32) , x86_64 and ARM platforms, with PPC being stalled. It supports all of the core language, passing the Python test suite (with minor modifications that were already accepted in the main python in newer versions). It supports most of the commonly used Python standard library modules. For known differences with CPython, see our compatibility page.
If you are interested in helping to move forward, see our howtohelp page.
We also have a beta release of PyPy3 which implements Python 3.2.5. It runs on the same platforms as above.
The main features of PyPy:
There are two cases that you should be aware where PyPy will not be able to speed up your code:
- Short-running processes: if it doesn't run for at least a few seconds, then the JIT compiler won't have enough time to warm up.
- If all the time is spent in run-time libraries (i.e. in C functions), and not actually running Python code, the JIT compiler will not help.
So the case where PyPy works best is when executing long-running programs where a significant fraction of the time is spent executing Python code. This is the case covered by the majority of our benchmarks, but not all of them – the goal of PyPy is to get speed but still support (ideally) any Python program.
Memory-hungry Python programs (several hundreds of MBs or more) might end up taking less space than they do in CPython. It is not always the case, though, as it depends on a lot of details. Also note that the baseline is higher than CPython's.
PyPy has many secondary features and semi-independent projects. We will mention here:
PyPy's sandboxing is a working prototype for the idea of running untrusted user programs. Unlike other sandboxing approaches for Python, PyPy's does not try to limit language features considered “unsafe”. Instead we replace all calls to external libraries (C or platform) with a stub that communicates with an external process handling the policy.
|Please be aware that it is a prototype only. It needs work to become more complete, and you are welcome to help. In particular, almost none of the extension modules work (not even time ), and pypy_interact is merely a demo. Also, a more complete system would include a way to do the same as pypy_interact from other languages than Python, to embed a sandboxed interpreter inside programs written in other languages.|
To run the sandboxed process, you need to get the full sources and build pypy-sandbox from it (see Building from source). These instructions give you a pypy-c that you should rename to pypy-sandbox to avoid future confusion. Then run:
cd pypy/sandbox pypy_interact.py path/to/pypy-sandbox # don't confuse it with pypy/goal/pyinteractive.py!
You get a fully sandboxed interpreter, in its own filesystem hierarchy (try os.listdir('/')). For example, you would run an untrusted script as follows:
mkdir virtualtmp cp untrusted.py virtualtmp/ pypy_interact.py --tmp=virtualtmp pypy-sandbox /tmp/untrusted.py
Note that the path /tmp/untrusted.py is a path inside the sandboxed filesystem. You don't have to put untrusted.py in the real /tmp directory at all.
To read more about its features, try pypy_interact.py --help or go to our documentation site.