The Linux Foundation

 
Python 3

From The Linux Foundation

This is the page for planning the uplift to Python 3, possibly scheduled for LSB 5.0.

A lsb-discuss thread discussing this plan can be found here.

Contents

Version

We need to figure out which version of Python 3 to standardize on.

Table of distribution support for Python 3:

Distribution Python 3 Version python3? python2? /usr/bin/python version Notes
Ubuntu 12.04 LTS 3.2.3 yes yes python2
Ubuntu 12.10 3.2.3 yes yes python2
Fedora 17 3.2.3 yes yes python2
Fedora 18 3.3.0 yes yes python2
Opensuse 12.2 3.2.3 yes yes python2

Interpreter Name

Per PEP 394, distros should currently be shipping a "python2" and a "python3" binary for the Python 2 and Python 3 interpreters, respectively. "python" can be either; it's encouraged to keep it as Python 2, but not required.

The idea is that scripts built to handle either Python 2 or Python 3 can be called with "python"; scripts requiring one or the other should use the version-specific binary. Of course, the problem is that legacy scripts will still expect "python" to be Python 2.

From an LSB perspective, we should either deprecate use of the "python" interpreter, or require that apps using "python" work with both 2 and 3. We should add "python2" to the existing Python 2 spec, and "python3" should be a part of the new Python 3 spec.

Modules

We will need to make changes to the way modules are handled.

Module List

We will need a new module list. PEP 3108 lists changes in modules from Python 2 to 3; this will be helpful in generating our list.

Symbol Tracking in Modules (optional)

We currently do not require any specific set of symbols in each module. We could include this, along with a test to make sure the module contains the symbols it should. This is optional, however.

Tests

Runtime Test

We will need to get the python-test build to do a set of Python 3 tests, possibly with the same kind of tweaks we currently apply to the Python 2 tests.

lsbappchk-python

This will need to detect the app's requirements (2 or 3), and check against different sets of criteria depending on that result. For scripts which work against both (see #Interpreter Name, above), we should test against the "non-deprecated-or-trial-use" Python version.

Application Checker

This utility does some direct Python tests, specifically at this path:

utils/interpreted languages/analyze_python.py

These will need to be ported to Python 3 as well.

Time Estimate

Task Time
Distribution survey/version decision 3 days
Interpreter issue 1 day
Module list 1 day
Module symbol tracking  ? (optional)
Database and regeneration work 1 week
Porting python-test 2 weeks
Porting lsbappchk-python 1 week
Port App Checker 2 days
Total 4 weeks, 6 days

[Article] [Discussion] [View source] [History]