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.18, 3.9.15, and 3.8.15. It supports all of the core language. 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, and Apple Silicon arm64)
PowerPC 64bit both little and big endian
PyPy's x86 version runs on several operating systems, such as Linux (32/64 bits), MacOS (64 bits), Windows (32 bits), OpenBSD, FreeBSD. Non-x86 versions are supported on Linux, and ARM64 is supported on MacOS.
If you are interested in helping, 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.
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:
You get a fully sandboxed interpreter, in its own filesystem hierarchy
os.listdir('/')). For example, you would run an untrusted
script as follows:
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.