From Fedora Project Wiki

< Changes

Revision as of 07:39, 4 October 2013 by Bkabrda (talk | contribs) (How To Test)

Python 3 as Default


Up until now, Fedora has used Python 2 as a default Python implementation. This change proposes switching to Python 3. The term "switching" is explained in detail in Scope section.


  • Name: Slavek Kabrda
  • Email:
  • Release notes owner:

Current status

Detailed Description

Python 3 is the next generation of Python programming language. It is currently mature and stable, since it has been under active development for five years - 3.0 was released in December 2008, current latest stable version is 3.3.2 released in May 2013. The reasons why to switch to Python 3 as a default are mentioned in #Benefit to Fedora section, possible issues in #Scope. This feature assumes that DNF will be the default package manager in F22, as Yum doesn't and never will work with Python 3. If DNF doesn't make it to Fedora 22, this feature has to be postponed accordingly.

Benefit to Fedora

Python 2.7 (latest Python 2 release, which we also have in Fedora) is currently in maintenance mode only, which means upstream only accepts bugfixes and security fixes, but no new features are being implemented. According to upstream, Python 2.7 is the last release of Python 2 ( Support for Python 2 is guaranteed by upstream until May 2015 (, then it may continue for some time or it may not. Python 3, on the other hand, is actively developed and new features are being added every release.

Fedora already has Python 3 stack, that is parallel to Python 2 stack. The are few benefits of switching the "primary" Python stack:

  • Getting upstream support for default system version will not be limited by time.
  • Our system tools will be able to switch to Python 3, drop the burden of Python 2 support and use new features of Python 3.
  • As a distribution that stays close to upstream, Fedora should help Python community go forward by contributing patches and working closely with upstreams to get this accomplished. Thus this Change is meant to benefit not only Fedora, but also broad Python community.
  • Switching to Python 3 as a default will once again push Fedora to stay as close to upstream as possible, highlighting the "Features" and "First" (although, to be honest, Arch Linux was first in this...)


The main goal is switching to Python 3 as a default, in which state:

  • DNF is the default package manager instead of Yum, which only works with Python 2
  • Python 3 is the only Python in minimal buildroot
  • Python 3 is the only Python on LiveCD
  • Anaconda and all of its dependencies run on Python 3
  • cloud-init and all of its dependencies run on Python 3

(see Dependencies for the list of packages that need to be ported)

This will also require revisiting Python guidelines (broader discussion with community and FPC approval - TBD). The result of the discussion will reflect in this feature in further instructions for Fedora packagers.

There are basically two types of packages that need to undergo the conversion:

  • Python extension modules and libraries that provide Python bindings - assuming that there is upstream support, these can recieve python3- subpackage anytime without any damage to Fedora; we can then just utilize this subpackage when switching to Python 3 (instead of using current python- subpackage).
  • Packages that build with some sort of "embedded Python support", like gdb, or Rhythmbox with its plugins. In these cases, it makes no sense to do a python3- subpackage, since the whole package would need to be duplicated (e.g. python3-gdb), which doesn't make sense. These packages should be tested with Python 3 locally without any modifications to how they're currently built in Fedora. When we get a Koji side-tag, these packages will switch and build against Python 3 in the side tag.

Work in Fedora 21 Timeframe

  • Proposal owners:
    • Discussing changes in Python packaging guidelines with Fedora community and FPC
    • Helping upstreams with porting to Python 3
    • Introducing python3- packages where appropriate, testing packages that only build with Python once (e.g. gdb, Rhythmbox)
  • Other developers:
    • Hopefully the same as proposal owners.
  • Release engineering:
    • Nothing in F21 timeframe
  • Policies and guidelines:
    • As mentioned above, this will require a discussion with community and FPC and preparation of changes to Python packaging guidelines. The changes related to the actual switch should however be merged in F22 timeframe and only if the switch is successful.

Work in Fedora 22 Timeframe

  • Proposal owners:
    • Continue the work from F21 timeframe
    • Request Koji side-tag and encourage packagers to rebuilt their packages with Python 3 there
    • If the switch to Python 3 is achieved in the side-tag:
      • Modify comps accordingly
      • Apply the changes to Python packaging guidelines
      • Ask relengs to merge the side tag into F22
    • Else:
      • Postpone the Change for another release
      • Do not merge side tag into F22
      • Do not apply changes to Python packaging guidelines
  • Other developers:
    • Introduce python3- subpackages where appropriate, build against Python 3 in the side tag where appropriate
  • Release engineering:
    • Create the Koji side tag
    • Merge the side tag back in F22 if the switch is achieved
  • Policies and guidelines:
    • Apply the changes to Python guidelines if the switch is achieved

Upgrade/compatibility impact

The Python 2 stack will stay in Fedora, it will just not be the default one. Depending on the modifications done to Python packaging guidelines, this probably means that Python 2 packages will stay the way they are and default tools will drag in python3- dependencies. Upstream recommends, that /usr/bin/python should point to Python 2 runtime for the time being, so if we go with that, there shouldn't be any serious compatibility impact:

  • Users will still be able to install Python 2 packages
  • Both Python 2 and 3 stacks will still live in parallel

Libraries that are built with Python only once (like gdb) may force users to rewrite their custom scripts and plugins (see e.g.

How To Test

  • No special hardware is needed.
  • Using mock for testing is strongly recommended. During rebuilding in the Koji side tag, things may get unstable and you'd be risking breaking your system.
  • Install the packages built against Python 3 from the Koji side tag and test if they still work as expected.
  • When the switch is prepared in the side tag, just try installing the packages from there and removing Python 2 from your system. Again, look for any problems that may be related to the switch.

User Experience

Users shouldn't notice any change in behaviour, except from installation of python3- packages by default.


See (our tracking page with notes) or (tracking bug).

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Don't merge the koji side-tag into rawhide, revert changes in dist-git.
  • Contingency deadline: Development freeze
  • Blocks release? No


Release Notes