From Fedora Project Wiki
m (→‎Scope: change column heading)
No edit summary
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{admon/important|Old page|This page is a ''Feature page'' for Fedora 15 (that's history). It is not a general information page about PyPy in Fedora. Expect everything here to be outdated. Do not update it.}}
<!-- All fields on this form are required to be accepted by FESCo.
<!-- All fields on this form are required to be accepted by FESCo.
  We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
  We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
Line 7: Line 8:


== Summary ==
== Summary ==
{{FedoraVersion|long|next}} has an alternate Python 2 runtime and add-on module stack built using PyPy, an alternate implementation of the Python 2 language, featuring Just-in-Time compilation.
Fedora N+1 <!-- {{FedoraVersion|long|next}} --> has an alternate Python 2 runtime and add-on module stack built using PyPy, an alternate implementation of the Python 2 language, featuring Just-in-Time compilation.


== Owner ==
== Owner ==
Line 17: Line 18:


== Current status ==
== Current status ==
* Targeted release: [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]]  
* Targeted release: Fedora 16? <!-- [[Releases/{{FedoraVersion||next}} | {{FedoraVersion|long|next}} ]] -->
* Last updated: 2011-01-13
* Last updated: 2011-05-03
* Percentage of completion: 30%
* Percentage of completion: 30%


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->


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 ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
[http://pypy.org/ PyPy] is a python interpreter written in a subset of python.  The interpreter can have  [http://morepypy.blogspot.com/2009/10/gc-improvements.html better memory] use than CPython and speed is closing in on Cpython. The JIT'd version is faster than CPython in many [http://speed.pypy.org benchmarks].
[http://pypy.org/ PyPy] is a fast, compliant alternative implementation of the Python language (2.7.10). It has several advantages and distinct features. Thanks to its Just-in-Time compiler, Python programs often run faster on PyPy. Memory-hungry Python programs (several hundreds of MBs or more) might end up taking less space than they do in CPython.
 
It is growing the ability to [http://morepypy.blogspot.com/2010/04/using-cpython-extension-modules-with.html load CPython extension modules].


This feature is exploring the idea of shipping PyPy, and the scope is not yet clear, be it:
This feature is exploring the idea of shipping PyPy, and the scope is not yet clear, be it:
Line 54: Line 66:


<!-- Please keep this table sorted alphabetically by python module name -->
<!-- Please keep this table sorted alphabetically by python module name -->
An upstream guide to PyPy compatibility can be seen at https://bitbucket.org/pypy/compatibility/wiki/Home
{|
{|
! Python Module !! Fedora CPython package !! PyPy Compatibility and Notes !! Fedora PyPy status
! Python Module !! Fedora CPython package !! PyPy Compatibility and Notes !! Fedora PyPy status
Line 65: Line 78:
| dbus    || dbus-python || ||
| dbus    || dbus-python || ||
|-
|-
| gtk      || pygtk2      || ||
| django  || Django      || ||
|-
| gtk      || pygtk2      || I filed an [https://codespeak.net/issue/pypy-dev/issue620 upstream bug relating to ./configure]; after that there are [https://codespeak.net/issue/pypy-dev/issue625 multiple compilation errors] ||
|-
|-
| lxml    || python-lxml || ||
| lxml    || python-lxml || ||
|-
|-
| gobject  || pygobject2  || ||
| gobject  || pygobject2  || ||
|-
| MySQLdb  || MySQL-python || || {{bz|669835}}
|-
| numpy    || numpy      || ||
|-
| psycopg2 || python-psycopg2 || See also https://github.com/mvantellingen/psycopg2-ctypes ||
|-
| PyKDE4  || PyKDE4 (from the kdebindings srpm) || ||
|-
|-
| PyQt4    || PyQt4      || ||
| PyQt4    || PyQt4      || ||
|-
| rpm      || rpm-python (subpackage of "rpm")|| ||
|-
| scipy    || scipy      || ||
|-
|-
| selinux  || libselinux-python || (generated by SWIG during build of libselinux) ||  
| selinux  || libselinux-python || (generated by SWIG during build of libselinux) ||  
Line 77: Line 104:
| semanage || libsemanage-python || (generated by SWIG during build of libsemanage) ||  
| semanage || libsemanage-python || (generated by SWIG during build of libsemanage) ||  
|-
|-
| setuptools || python-setuptools || ( we've switched to the "Distribute" fork) ||
| setuptools || python-setuptools || ( we've switched to the "Distribute" fork) || {{bz|669825}}
|-
|-
| sip      || sip        || ||
| sip      || sip        || ||
|-
|-
| sqlalchemy || python-sqlalchemy || ||
| sqlalchemy || python-sqlalchemy || ||
|-
| virtualenv || python-virtualenv || ||
|}
|}


Line 126: Line 155:
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
[[Category:Python]]

Latest revision as of 13:07, 14 April 2016

Important.png
Old page
This page is a Feature page for Fedora 15 (that's history). It is not a general information page about PyPy in Fedora. Expect everything here to be outdated. Do not update it.


PyPy Stack

Summary

Fedora N+1 has an alternate Python 2 runtime and add-on module stack built using PyPy, an alternate implementation of the Python 2 language, featuring Just-in-Time compilation.

Owner

  • Email: <dmalcolm@redhat.com>

Current status

  • Targeted release: Fedora 16?
  • Last updated: 2011-05-03
  • Percentage of completion: 30%


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

yum install pypy

See the package review)

We currently have PyPy-1.5

There is a tracker bug for the PyPy stack in Red Hat bugzilla.

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)
  • 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.

Detailed Description

PyPy is a fast, compliant alternative implementation of the Python language (2.7.10). It has several advantages and distinct features. Thanks to its Just-in-Time compiler, Python programs often run faster on PyPy. Memory-hungry Python programs (several hundreds of MBs or more) might end up taking less space than they do in CPython.

This feature is exploring the idea of shipping PyPy, and the scope is not yet clear, be it:

  1. just the core interpreter, or
  2. sharing pure-Python add-on modules with the system Python (but with split bytecode files), or
  3. a full, independent Python stack, but with just pure-Python add-on modules, or
  4. a full, independent Python stack, with both pure-Python and machine-code extension modules

Benefit to Fedora

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.

Scope

An upstream guide to PyPy compatibility can be seen at https://bitbucket.org/pypy/compatibility/wiki/Home

Python Module Fedora CPython package PyPy Compatibility and Notes Fedora PyPy status
swig
cairo pycairo
coverage python-coverage
dbus dbus-python
django Django
gtk pygtk2 I filed an upstream bug relating to ./configure; after that there are multiple compilation errors
lxml python-lxml
gobject pygobject2
MySQLdb MySQL-python RHBZ #669835
numpy numpy
psycopg2 python-psycopg2 See also https://github.com/mvantellingen/psycopg2-ctypes
PyKDE4 PyKDE4 (from the kdebindings srpm)
PyQt4 PyQt4
rpm rpm-python (subpackage of "rpm")
scipy scipy
selinux libselinux-python (generated by SWIG during build of libselinux)
semanage libsemanage-python (generated by SWIG during build of libsemanage)
setuptools python-setuptools ( we've switched to the "Distribute" fork) RHBZ #669825
sip sip
sqlalchemy python-sqlalchemy
virtualenv python-virtualenv

How To Test

User Experience

Dependencies

Contingency Plan

Documentation

Release Notes

Comments and Discussion