SIGs/Python

Python Special Interest Group

A SIG for people who are interested in Python on Fedora. This includes:

• packaging and optimizing the various Python 2 and Python 3 Python runtimes
• packaging Python libraries and applications
• setting and improving standards for packaging them as RPMs
• maintaining Python packages for Fedora

Contact Info

Mailing List: python-devel
IRC: #fedora-python on irc.freenode.net

Python SIG FAS group

You can add group::python-sig to your package so the core members of the python-sig get notified on each bug in your python program. This way it is possible to maintain all python packages with the group permissions, which will simplify general python cleanup changes.

If there is interest and shown familiarity with our guidelines and processes (which usually manifests in maintaining at least 5 to 10 Python packages) you can apply for having access to a broader group of packages that is commonly maintained. If you choose to apply for this, please discuss it with a sponsor of the python-sig. (You can find a list of those in FAS.)

The current list of packages maintained by the python-sig can be found at the package database.

Members

Martin Bacovsky
Luis Bazán
Aurelien Bompard
Nick Coghlan
Kushal Das
Christian Dersch
Tejas Dinkar
Tadej Janež
Bohuslav Kabrda
Matej Stuchlik
Andrew Colin Kissa
Toshio Kuratomi
Alex Lancaster
Tim Lauridsen
José Matos
Luke Macken
Abdel Martínez
Dave Malcolm: interested in core Python runtimes and low-level implementation details
Paul Nasrat
Jamie Nguyen
Tomas Radej
Michel Salim
Felix Schwarz
John Dulaney
Thomas Spura
Christos Trochalakis
Ramakrishna Reddy Yekulla
Ignacio Vazquez-Abrams
Praveen Kumar
Raphael Groner
Athmane Madjoudj
Robert Kuska
Miro Hrončok

Python packages awaiting review

• List of most python packages awaiting review - Bugzilla query for packages which have not passed review with "python" in the name or summary.

Packaging Quickstart

If you're just getting started with packaging python modules for Fedora, here's some hints to get you started:

• The Fedora Packaging Guidelines must be followed for any package. The Python specific guidelines are a good starting point.
• You can generate a spec template for your new python package like this. For Fedora 22 and later versions use DNF:

  dnf install rpmdevtools && rpmdev-newspec -t python

  Or in Fedora 21 and earlier versions:

  yum install rpmdevtools && rpmdev-newspec -t python

  That will generate a spec file template that is a good starting point to making your package.
• When packaging PyPI project you can generate initial SPEC file using pyp2rpm tool.

Package requests

• Chandler PIM - I don't think it is such hot idea ... upstream is pinning for the fjords, and after couple of years of non-development, it is not that advanced as it used to be.
• itools - A python library that includes several useful tools, such as an ODF anonymizer that can be used to sanitize confidential documents before attaching them tp bug reports

review request

• python-multiprocessing - multiprocessing backport useful for EL-5 review request
• repoze.profile - WSGI profiling middleware
• tgscheduler - TurboGears scheduler

Links

Python website
Building Python packages
Python Patches
TurboGears
Packaging TurboGears Applications
Packaging Python Eggs
Parallel installable Python26 information (mainly EPEL5).
Unicode in Python, Completely Demystified

Upstream Release Schedules

Python 3.4 Python 3.5 Python 3.6

Python Features

Future work

• port anaconda and yum to python 3
• debug versions of Python 2 and Python 3 in addition to the traditional optimized builds
• add PyPy to Fedora, possibly with a stack of extensions
• add a stack of extensions to Jython, in RPM form
• Rename python packages to reflect python implementation in the name

Under development (Fedora 18)

• upgrade of the Python 3 stack to 3.3

Added in Fedora 17

• further work on static analysis of refcounting

Added in Fedora 16

• GCC plugin embedding Python, for writing GCC extensions in Python
• Static analysis tool to detect common mistakes made in Python extension modules written in C

Added in Fedora 15

• upgrade of the Python 3 stack to 3.2

Added in Fedora 14

• upgrade of the Python 2 stack to 2.7
• pypy was packaged, available prebuilt via rpm

Added in Fedora 13

• parallel-installable Python 3 stack
• gdb hooks to make it easier to debug Python and extension modules
• Systemtap probe points for tracing Python function calls

Added in Fedora 11

• upgrade of the Python 2 stack to 2.6

Added in Fedora 10

• created and packaged bindings for the FIPS-validated NSS cryptographic library

Stalled features

• Features/SystemPythonExecutablesUseSystemPython

Python Runtimes

Within Fedora:

• python - The standard "CPython" implementation of Python 2
• python3 - As above, for Python 3. There's a separate page detailing the status of building up a stack of pre-packaged Python 3 modules
• jython - Python 2 implementation on top of the Java virtual machine
• pypy - An alternate python 2 interpreter (with a JIT-compiler) written in a subset of python, compiled to .c. The interpreter has better memory use than CPython and speed is closing in on CPython. The JIT'd version is faster than CPython in many benchmarks. It is growing the ability to load CPython extension modules, though this is in an "alpha" state right now.

Within EPEL:

• python26 - Python 2.6 stack for EPEL5, parallel-installable with the system Python 2.4 stack

Awaiting review:

• pynie - Python 3, on top of the Parrot virtual machine

Awaiting packaging

• IronPython
  • Ironclad CPython extensions from IronPython
• Python-on-a-Chip (p14p)

Python Compilers

Within Fedora:

• pyjamas - Python-to-JavaScript compiler, implemented in Python
• shedskin - Python to C++ compiler (for a subset of Python with "implicit types")