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 implements Python 2.7.13 and 3.6.9. It supports all of the core language, passing the Python 2.7 test suite and most of the 3.6 test suite (with minor modifications) It supports most of the commonly used Python standard library modules. For known differences with CPython, see our compatibility page.
The following CPU architectures are supported and maintained:
ARM platforms (ARMv6 or ARMv7, with VFPv3)
PowerPC 64bit both little and big endian
PyPy's x86 version runs on several operating systems, such as Linux (32/64 bits), Mac OS X (64 bits), Windows (32 bits), OpenBSD, FreeBSD. All non-x86 versions are only supported on Linux.
If you are interested in helping to move forward, see our howtohelp page.
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
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
To run the sandboxed process, you need to get the full sources and
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
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
directory at all.
To read more about its features, try
pypy_interact.py --help or go to
our documentation site.