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://fedora.portingdb.xyz/
openSUSE status: https://en.opensuse.org/openSUSE:Python_3_Status
Additional Python 3 porting helpers
Expansive Python 2/3 compatibility layer (provides a more "Python 3" experience in Python 2 than the more minimalist six compatibility module)
PyPI module: https://pypi.python.org/pypi/future
Fedora COPR: ??
Fedora review request:
"Six for extension modules"
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.
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.