Page started at PyCon 2015 for cross-distro collaboration on Python 3 Linux distro porting status.

Ubuntu status: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3

Fedora status: http://portingdb-encukou.rhcloud.com/

Additional Python 3 porting helpers

Python Future

Expansive Python 2/3 compatibility layer (provides a more "Python 3" experience in Python 2 than the more minimalist six compatibility module)

Documentation: http://python-future.org/

PyPI module: https://pypi.python.org/pypi/future

Ubuntu PPA (bio-linux): https://launchpad.net/~nebc/+archive/ubuntu/bio-linux/+packages?field.name_filter=python&field.status_filter=published&field.series_filter=

Fedora COPR: ??

Debian ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782250

Fedora review request:

py3c

"Six for extension modules"

Documentation: https://py3c.readthedocs.org/en/latest/

Possible revised semantics for "python" symlink

• Current semantics: "Python 2" (as per PEP 394)
• Suggested semantics: administrator controlled "default Python" with command line selection of alternative runtimes

Conceptually along the lines of the "Python launcher for Windows" (https://www.python.org/dev/peps/pep-0397/), but wouldn't automatically update to refer to new versions when they were installed - the launcher configuration would need to be explicitly updated to select a new default.

Background reading

• Discussion at 2015 Python Language Summit: https://lwn.net/Articles/640296/

• linux-sig thread on providing a "py" launcher: https://mail.python.org/pipermail/linux-sig/2015-October/000000.html

• Geoffrey Thomas's "python" launcher concept for Debian: https://ldpreload.com/blog/usr-bin-python-23

Why not the "alternatives" system?

• Debian alternatives: https://wiki.debian.org/DebianAlternatives

• Fedora alternatives: https://fedoraproject.org/wiki/Packaging:Alternatives

The problem with the alternatives system for this use case is that there's no support for command line overriding of the selected version - "python" would always refer to the administrator selected version. We'd prefer the runtime selectivity offered by the Python launcher for Windows CLI or Fedora's rubypick (https://github.com/fedora-ruby/rubypick)

Possible integration with Software Collections & Environment Modules

Software collections are a tool for the Fedora/RHEL/CentOS ecosystem that allows parallel installation of multiple versions of language, database and web server runtimes: https://www.softwarecollections.org/en/

SCL 2.0+ natively supports the cross-distro environment modules system (http://modules.sourceforge.net/), while SCL 1.x supports automated conversion to environment modules (https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html/Packaging_Guide/sect-Converting_Software_Collection_Scriptlets_into_Environment_Modules.html)

If "/usr/bin/python" becomes a Python launcher style executable rather than a direct symlink to a specific Python runtime, then it would likely be desirable to make it easy to have it point to a software collection or other environment module installed under /opt in addition to being able to use it to switch between native system packages installed under /usr.

Other Notes/Tasks

Update Python 3 extension module porting guide (https://docs.python.org/dev/howto/cporting.html): https://bugs.python.org/issue23897 (Barry Warsaw, Petr Viktorin)

Use https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef#Python_extension_modules