pypy-1.4.1 is packaged within Fedora (see the [https://bugzilla.redhat.com/show_bug.cgi?id=588941 package review])

+

PyPy has been packaged within Fedora from Fedora 15 onwards, and is available via:

+

+

<pre>

+

yum install pypy

+

</pre>

+

+

See the [https://bugzilla.redhat.com/show_bug.cgi?id=588941 package review])

+

+

We currently have PyPy-1.5

+

+

There is a [https://bugzilla.redhat.com/showdependencytree.cgi?id=669836&hide_resolved=1 tracker bug for the PyPy stack] in Red Hat bugzilla.

Areas of uncertainty:

Areas of uncertainty:

* as of 1.4.1, support for .c extensions (using the CPython API) is still experimental (need to try some extensions and see what works)

* as of 1.4.1, support for .c extensions (using the CPython API) is still experimental (need to try some extensions and see what works)

* 1.4.1 ships with a bytecode format similar to (but slightly different from) CPython 2.5.1. It's not yet clear to me what the anticipated rate of change to the bytecode format is. If we build out a collection of pure-python extensions in RPM form (e.g. a pypy-django.rpm), with .pyc files, we don't want to be constantly having to rebuild them all as the precise bytecode format changes (even if we e.g. ported [http://www.python.org/dev/peps/pep-3147/ PEP 3147], we still ought to rebuild the RPMs)

* 1.4.1 ships with a bytecode format similar to (but slightly different from) CPython 2.5.1. It's not yet clear to me what the anticipated rate of change to the bytecode format is. If we build out a collection of pure-python extensions in RPM form (e.g. a pypy-django.rpm), with .pyc files, we don't want to be constantly having to rebuild them all as the precise bytecode format changes (even if we e.g. ported [http://www.python.org/dev/peps/pep-3147/ PEP 3147], we still ought to rebuild the RPMs)

+

+

Upstream work

+

* working on improving the readability of the 6 million lines of autogenerated C code emitted by the build; I've [http://codespeak.net/pipermail/pypy-dev/2010q4/006532.html sent patches upstream for this], but it's not yet finished.

== Detailed Description ==

== Detailed Description ==

Line 52:

Line 65:

== Scope ==

== Scope ==

<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->

<!-- What work do the developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->

as of 1.4.1, support for .c extensions (using the CPython API) is still experimental (need to try some extensions and see what works)

1.4.1 ships with a bytecode format similar to (but slightly different from) CPython 2.5.1. It's not yet clear to me what the anticipated rate of change to the bytecode format is. If we build out a collection of pure-python extensions in RPM form (e.g. a pypy-django.rpm), with .pyc files, we don't want to be constantly having to rebuild them all as the precise bytecode format changes (even if we e.g. ported PEP 3147, we still ought to rebuild the RPMs)

Upstream work

working on improving the readability of the 6 million lines of autogenerated C code emitted by the build; I've sent patches upstream for this, but it's not yet finished.

PyPy is a python interpreter written in a subset of python. The interpreter can have better memory use than CPython and speed is closing in on Cpython. The JIT'd version is faster than CPython in many benchmarks.

PyPy is an innovative implementation of the Python language, but it can take an hour to build, requiring a powerful machine. By providing an easy way for people to install a PyPy stack, we continue to push Fedora as an excellent platform for Python developers.

Fedora aims to showcase the latest and greatest in Free/Open Source Software: PyPy is certainly innovative.

Fedora heavily uses Python, both within the operating system itself, and within the infrastructure used by the project. As PyPy becomes more mature we may eventually want to migrate from CPython to PyPy for some of these workloads.