Python 3 Support: A Plan of Action

[Richard Wilbur]

On Sun, Sep 6, 2015 at 9:31 AM, Jelmer Vernooij <jelmer at samba.org> wrote:
> On Sat, Sep 05, 2015 at 11:30:25PM -0600, Richard Wilbur wrote:
>> On Fri, Sep 4, 2015 at 10:05 AM, Stefan Monnier
>> <monnier at iro.umontreal.ca> wrote:
>> >> I might suggest continuing to support Python 3.4 even after 3.5 is released,
>> >> at least for a little while.
>> >
>> > That's only an issue if you expect systems to come with Python3 < 3.5 but
>> > without Python2 >= 2.7.10
>> >
>> Agreed, Stefan.  Do you expect there will be many systems that package
>> Python2 < 2.7.10?  Looks like v2.7.10 was released on 23 May 2015.[0]
>> When do you think there will be widespread adoption of Python 2.7.10?
> It's likely to take at least a couple of years. Some distributions
> (e.g. RHEL) only release every couple of years, and after that it
> usually takes a while for their customers to upgrade.

That makes sense, Jelmer.  In that case what do you think would be the
best policy to avoid gratuitously leaving users (and their
bzr-packaging distributions) behind?

1.  Break with the past at the bzr v2.6 versus v2.7 boundary and
backport fixes to 2.6 for some acceptable length of time to allow
distributions and their users to catch up with the python version
requirements imposed by bzr 2.7.

2.  Create or use some compatibility implementation of new python
features that we use in bzr 2.7+ with a sundown date (planned
deprecation) an acceptable distance in the future "to allow
distributions and their users to catch up with the python" versions
that first implemented those features in the language.
    In other words, determine the lineage of new language features
we'd like to use (what version of python introduced them and when was
it released), then if it has not been available long enough to satisfy
our criteria for general availability/wide adoption, create or use a
feature implementation compatible with python versions that satisfy
said criteria.

This period (python release general availability/wide adoption) sounds
like it should be more than 2 years.  Do you think 4 years is
reasonable?

Another possibility would be to establish a consensus on what we
consider a representative sample of distributions in current use and
consider which versions of python they ship.  Then only change
expected python versions when those distributions update their
offerings and are in wide adoption.

Not that these are the only possible solutions, but they were the
first to come to mind.  I think #1 (break with the past) implies a
greater continuing effort over the duration for developers in that we
must support two baselines (2.6, 2.7+).  The compatibility effort in
#2 represents some additional initial effort but seems in the long
term to require considerably less work.  Especially since some of the
compatibility work has already been done by other friendly folk who
are eager to spare us the trouble of reinventing the wheel.  (And I
believe that is largely what we will be using to build a python 2/3
codebase in the first place.)

It seems #2 also significantly reduces the pressure to change our
python version requirements.

Python version/Release date[0]
2.7.10/23 May 2015
3.4.3/25 Feb 2015
2.7.9/10 Dec 2014
3.4.1/18 May 2014
3.4.0/27 Mar 2014
3.3.5/11 Mar 2014
3.3.4/9 Feb 2014
3.3.3/13 Nov 2013
2.7.6/10 Nov 2013
3.3.0/(scheduled for) 22 Sep 2012
3.2.1/11 Jul 2011
2.7.2/Jun 2011
3.1.4/Jun 2011
(Python Insider started 23 Mar 2011)[1]

Sincerely,
Richard

References:
[0] http://blog.python.org/
[1]  http://blog.python.org/search?updated-max=2011-04-06T12:44:00-04:00&max-results=7&start=42&by-date=false