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

<<TableOfContents()>>

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

Fedora status: http://fedora.portingdb.xyz/

openSUSE status: https://en.opensuse.org/openSUSE:Python_3_Status

= 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 [[https://www.python.org/dev/peps/pep-0397/|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)

Counter-argument: tools like 'conda', 'pyenv', 'virtualenv', and the Linux-specific utilities discussed in the next section already offer environment based control over which Python you get on a per user and per application basis, so an administrator set default is arguably the only missing piece, and that's exactly the problem the alternatives system is designed to handle.

== 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