Python 3 Support: A Plan of Action

[Richard Wilbur]

Greetings Developers,

I am in favor of supporting python 3 and articulated a plan back 2014
in order to add that support.[0]  In the light of subsequent
developments, I'd like to revisit that plan.

Let's start with a branch strategy:
2.6.x:  (requires python 2.6+) Back ports of bug fixes.
2.7:  New branch to require python 2.7.10+ or 3.4+.  Modernized python 2 code.
2.8:  New branch to add python 3 support.

Elaborating the previous plan:
Step -1:  Register any missing extras[1] and plugins[2] on bzr web
site.  Document extras and plugins.  Cleanup.  pep8 and other
stylistic mop up.  Release as 2.6.x.
     Avoid leaving plugins and extras behind and try to get a handle
on the scope of the subsequent effort.  (This would be a fine time to
find out and document [in a bug] what needs to be done to resurrect
orphaned plugins.  May entail locating last known good code, creating
a launchpad project, pushing the code, and filing a bug.  Then we have
an idea of what needs to be done if someone would like to contribute
effort.)

Step 0:  Setup.  Adjust required and installed Python versions.
Observe (and document) the tests passing on Python 2 and failing on Python 3.
    Require Python 2.7.10+ or 3.4+ in order to run.  Release as bzr 2.7.0

Step 1:  Modern Python 2 code.
    Modernize the Python 2 code without introducing any dependencies.
Release as bzr 2.7.1+ (release at the completion of each module)

Step 2: Working Python 3 code that still supports Python 2
    Get the tests passing first on Python 3 and then on Python 2 again
with the help of the 'future' package (from which we are already
importing absolute_import) and a PEP461 pure Python implementation for
byte %-formatting, et cetera.
    Release as bzr 2.8.x (release at the completion of each module)

Other developers who have been down this path before describe aspects
of the process and important details and considerations in "Easy,
clean, reliable Python 2/3 compatibility".[3]

Since python 3.5 is currently in release candidate form, by the time
we are ready for step 0 we may be able to require python 2.7.10+ or
3.5+!  I expect this will simplify some of the issues regarding
dealing with bytes and disk or network/wire formats.  (As of 10 Aug
the expected release date for python 3.5 is mid-September.)[4]

I expect this can be done, at least through step 1 (Modernize python 2
code), without changing external API's provided by bzr.  That would
greatly simplify interoperability with existing plugins and extras.

Sincerely,
Richard

Reference:
[0]  http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/75189
[1]  http://wiki.bazaar.canonical.com/BzrExtras
[2]  http://wiki.bazaar.canonical.com/BzrPlugins
[3]  http://python-future.org/porting.html
[4]  http://blog.python.org/2015/08/python-3.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+PythonInsider+%28Python+Insider%29