Python Special Interest Group
Python is a high-level, interpreted programming language which emphasizes on code readability. Fedora loves Python and this SIG is for people who are interested in Python on Fedora. We aim to address the issues and tasks related to everything-Python on Fedora which includes:
- Packaging and optimizing the various Python 2 and Python 3 runtimes
- Packaging Python libraries and applications
- Setting and improving standards for packaging them as RPMs
- Maintaining Python packages for Fedora
and much more...
|python-devel||General mailing list for all things Python related|
|#fedora-python||Python SIG official channel|
See SIGs/Python/Members_list for a list of our current core members.
Join Python SIG
We're always looking for new members to join us. Whether you're a new contributor or someone that's been around since the beginning, there are definitely ways you can help. Join Python SIG and:
- Build your portfolio by working on real-world projects
- Learn how to package new Python software
- Work with teammates from the four corners of the world
- Broaden your scope of working in open source communities and gain experience interacting in different areas
Areas of contribution
1. Packaging and maintaining Python applications
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:
dnf install rpmdevtools && rpmdev-newspec -t pythonThat will generate a spec file template that is a good starting point to making your package.
- When packaging PyPI project you can generate the initial SPEC file using pyp2rpm tool.
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.
2. Review Python packages
If you are one of the experienced Python packgers, you can help with the list of Python packages awaiting review.
- Bugzilla query for packages which have not passed review with "python" in the name or summary.
3. Porting to Python3
Currently there is an ongoing effort to port packages from Python 2 to Python 3, for the packages where upstream supports Python 3, so the package can provide either two subpackages for Python 2 and Python 3 respectively, or only the Python 3 version. This effort aims to completely shift to Python 3 before Python 2 retires in 2020.
Contributors interested in porting packages are encouraged to read the Python RPM Porting Guide
People who successfully port a number of packages are awarded the Parselmouth badge, and a separate wiki page is maintained with contributor's names and the packages they ported: Python 3 Log
You can track the overall progress at Fedora Porting Database.
Upstream Release Schedules
- Port anaconda and yum to Python3.
- Debug versions of Python2 and Python3 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 26)
See the History of Python Changes
- The standard "CPython" implementation of Python 2
- As above, for Python 3. There's a separate page detailing the status of building up a stack of pre-packaged Python 3 modules
- Python 2 implementation on top of the Java virtual machine
- 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.
- Python 2.6 stack for EPEL5, parallel-installable with the system Python 2.4 stack
- Python 3.4 stack for EPEL7
- Python to C++ compiler (for a subset of Python with "implicit types")