PyPy2.7 and PyPy3.5 v5.7 - two in one release¶
The PyPy team is proud to release both PyPy2.7 v5.7 (an interpreter supporting Python v2.7 syntax), and a beta-quality PyPy3.5 v5.7 (an interpreter for Python v3.5 syntax). The two releases are both based on much the same codebase, thus the dual release. Note that PyPy3.5 supports Linux 64bit only for now.
This new PyPy2.7 release includes the upstream stdlib version 2.7.13, and PyPy3.5 (our first in the 3.5 series) includes the upstream stdlib version 3.5.3.
We continue to make incremental improvements to our C-API compatibility layer (cpyext). PyPy2 can now import and run many C-extension packages, among the most notable are Numpy, Cython, and Pandas. Performance may be slower than CPython, especially for frequently-called short C functions. Please let us know if your use case is slow, we have ideas how to make things faster but need real-world examples (not micro-benchmarks) of problematic code.
Work proceeds at a good pace on the PyPy3.5
version due to a grant from the Mozilla Foundation, hence our first 3.5.3 beta
release. Thanks Mozilla !!! While we do not pass all tests yet, asyncio works and
as these benchmarks show it already gives a nice speed bump.
We also backported the
f"" formatting from 3.6 (as an exception; otherwise
“PyPy3.5” supports the Python 3.5 language).
CFFI has been updated to 1.10, improving an already great package for interfacing with C.
We now use shadowstack as our default gcrootfinder even on Linux. The alternative, asmgcc, will be deprecated at some future point. While about 3% slower, shadowstack is much more easily maintained and debuggable. Also, the performance of shadowstack has been improved in general: this should close the speed gap between Linux and other platforms.
As always, this release fixed many issues and bugs raised by the growing community of PyPy users. We strongly recommend updating.
You can download the v5.7 release here:
We would like to thank our donors for the continued support of the PyPy project.
We would also like to thank our contributors and encourage new people to join the project. PyPy has many layers and we need help with all of them: PyPy and RPython documentation improvements, tweaking popular modules to run on pypy, or general help with making RPython’s JIT even better.
What is PyPy?¶
PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7 and CPython 3.5. It’s fast (PyPy and CPython 2.7.x performance comparison) due to its integrated tracing JIT compiler.
We also welcome developers of other dynamic languages to see what RPython can do for them.
The PyPy 2.7 release supports:
x86 machines on most common operating systems (Linux 32/64 bits, Mac OS X 64 bits, Windows 32 bits, OpenBSD, FreeBSD)
newer ARM hardware (ARMv6 or ARMv7, with VFPv3) running Linux,
big- and little-endian variants of PPC64 running Linux,
s390x running Linux
Highlights of the PyPy2.7, cpyext, and RPython changes (since 5.6 released Nov, 2016)¶
See also issues that were resolved
New features and cleanups
update the format of the PYPYLOG file and improvements to vmprof
emit more sysconfig values for downstream cextension packages including properly setting purelib and platlib to site-packages
detect and raise on recreation of a PyPy object from a PyObject during tp_dealloc
refactor and clean up poor handling of unicode exposed in work on py3.5
builtin module cppyy supports C++ 11, 14, etc. via cling (reflex has been removed)
weakrefaccording to CPython issue 19542, will be in CPython 2.7.14
support translations with cpyext and the Boehm GC (for special cases like RevDB
StringBuffer.get_raw_addressfor the buffer protocol, it is now possible to obtain the address of any readonly object without pinning it
refactor the initialization code in translating cpyext
use a cffi-style C parser to create rffi objects in cpyext, now the translating Python must have either
move_to_end(last=True/False)on RPython ordered dicts, make available as
__pypy__.move_to_endand, on py3.5,
remove completely RPython
space.wrapin a major cleanup, differentiate between
any uncaught RPython exception in the interpreter is turned into a SystemError (rather than a segfault)
add translation time –disable_entrypoints option for embedding PyPy together with another RPython VM
"".replace("", "x", num)to give the same result as CPython
create log files without the executable bit
clock_gettime()on OS/X, since we support 10.11 and it was only added in 10.12
HAVE_FSTATVFSwhich was unintentionally always false
fix user-created C-API heaptype, issue 2434
PyDict_Updateis not actually the same as
PyTypeObjectand tie it to the app-level
__doc__attribute issue 2446
clean up memory leaks around
improve support for creating C-extension objects from app-level classes, filling more slots, especially
boolrestype, issue 2475
fix in corner cases with the GIL and C-API functions
allow overriding thread.local.__init__ in a subclass, issue 2501
PyClass_Newto be called with NULL as the first arguemnt, issue 2504
clean-ups in the jit optimizeopt
if x is not None: return xor
if x != 0: return x
jit.conditional_call_elidable(), a way to tell the JIT “conditonally call this function” returning a result
try harder to propagate
add and use
rgc.may_ignore_finalizer(): an optimization hint that makes the GC stop tracking the object
replace malloc+memset with a single calloc, useful for large allocations?
linux: try to implement os.urandom() as the syscall getrandom() if available
debug.ll_assert_not_none()through the JIT to reduce number of guards
improve the performance of
improve the optimization of branchy Python code by retaining more information across failing guards
add optimized “zero-copy” path for
improve the consistency of RPython annotation unions
add translation option –keepgoing to continue after the first AnnotationError
improve shadowstack to where it is now the default in place of asmgcc
add a rpython implementation of siphash24, allow choosing hash algorithm randomizing the seed
add rstack.stack_almost_full() and use it to avoid stack overflow due to the JIT where possible
Highlights of the PyPy3.5 release (since 5.5 alpha released Oct, 2016)¶
Development moved from the py3k branch to the py3.5 branch in the PyPy bitbucket repo.
this first PyPy3.5 release implements most of Python 3.5.3, exceptions are listed below
PEP 456 allowing secure and interchangable hash algorithms
use cryptography’s cffi backend for SSL
implement fixes for some CPython issues that arose since the last release
solve deadlocks in thread locking mechanism
do not create a list whenever
The following features of Python 3.5 are not implemented yet in PyPy:
PEP 442: Safe object finalization
PEP 489: Multi-phase extension module initialization
Please update, and continue to help us make PyPy better.