Python 3.5 as a system-wide change for Fedora 23?

Nick Coghlan ncoghlan at
Mon Jun 15 00:49:45 UTC 2015

Hi folks,

Toshio pinged me about a problem with dnf using -OO in their shebang
lines earlier today
(, which got me
thinking about our Python 3.5 adoption timeline (as I note in the
issue there, the reason using -OO in system packages is currently a
bad idea is a limitation in CPython's bytecode caching scheme that
Brett Cannon has fixed for 3.5+).

The two relevant schedule docs are the ones for F23 and Python 3.5:

Fedora 23:
Python 3.5:

The upstream Python 3.5rc1 release is due on August 9, while the final
release is due on September 13. To switch in F23 that would mean:

* getting a system-wide change for a Python 3 upgrade approved by the
F23 deadline on Jun 26
* getting a 3.5 beta release incorporated by the testability deadline
on July 28 (this would likely correspond to 3.5b3 upstream, which is
due for release on July 5)
* F23 Alpha would ship with a Python 3.5 beta release
* F23 Beta would ship with a Python 3.5 release candidate
* F23 final would ship with the Python 3.5.0 final release

Slavek's change proposal for the 3.4 upgrade in F21 is at

Progress on the "Python 3 as default" effort means that the Py3 stack
is significantly more critical now than it was back then. However, we
also have better testing tools available.

In particular, for testing purposes prior to making the change in
Koji, I'd suggest we consider Beaker's /distribution/rebuild task:

The example given there is for testing GCC changes, but it should work
for this as well (while isn't open for more
general access yet, I still have an account there from when I was
working on the Beaker team, and worst case, we can do the test on Red
Hat's Beaker internal instance instead).

The contingency plan if the Beaker rebuild showed significant problems
that couldn't be resolved by the testability deadline would be to
postpone the system-wide change to Fedora 24 (however, I'd consider
issues of that magnitude to indicate an upstream compatibility
problem, so it hopefully won't come to that)

If folks think this sounds like a plausible approach, I'd volunteer to
work with Matej as Python 3 maintainer to push it forward.


P.S. Miro's nightly SCLs at may
also have a part to play, although I'm not sure what that would be
just yet

Nick Coghlan   |   ncoghlan at   |   Brisbane, Australia

More information about the python-devel mailing list