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 only supports Linux 64bit 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
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 other platforms and Linux.
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 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.
We also welcome developers of other dynamic languages to see what RPython can do for them.
The PyPy 2.7 release supports:
Please update, and continue to help us make PyPy better.
Cheers, The PyPy team
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 other platforms and Linux.
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
¶
What else is new?¶
(since the releases of PyPy 2.7 and 3.3 at the end of 2016)
There are many incremental improvements to RPython and PyPy, the complete listing is here.
Cheers, The PyPy team
Comments
Awesome! Thanks, guys.
> We also backported the f"" formatting from 3.6 (as an exception; otherwise “PyPy3.5” supports the Python 3.5 language).
Could you also support just the syntax part of variable type declarations? It'll make using mypy that much nicer.
Awesome! Thanks a lot!
Hello.
Thanks for pypy!
I have a question: Is there any big company who using pypy in production?
Thanks
Great work as usual! Is there any plan to benefit from programs using PEP 484 syntax ?
@Canesin: benefit for performance? No. The PEP itself says "Using type hints for performance optimizations is left as an exercise for the reader". But that's a misleading comment. There is no useful optimization that we can apply from the knowledge "argument 1 is an int", because that could also be an arbitrarily-large integer and/or an instance of a subclass of int. And if it really turns out to be almost always a regular machine-sized integer, then PyPy's JIT will figure it out by itself. PEP 484 is totally pointless for performance. (It is probably useful for other reasons outside the scope of this comment.)
Excellent news! Is PyPy3 support for 32bit Linux planned? Thanks for info.
Miro: yes, we plan to have support for the same set of platforms. The various Posix platforms are not too much work, and Windows will follow, too.
Is there anybody working on win64? It is a bit frustrating to see pypy maturing quickly to the point that I could probably use it soon in production... if only it worked on win64.
Gaëtan: no. We need either outside contributions or, more likely, money to make it happen. Just like what occurred with Mozilla for Python 3.