Python 3 Support: A Plan of Action

[Jelmer Vernooij]

On Sun, Sep 06, 2015 at 10:40:06AM -0600, Richard Wilbur wrote:
> 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?

That's a tough question to answer. In the end, it comes down to the
right balance between burden to developers (avoiding new Python
features, or backporting fixes) vs burden to users (that are still on
older platforms).

If it was my call, I'd probably just focus on Python 2.7.10 and
Python3, and only backport essential bug fixes to Bazaar 2.6. The port
will take up some time as well - months, I imagine - and then there is
more time before a release actually happens. There are (currently)
also no must-have features in the new Bazaar that users on older
platforms would be deprived of.

> 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.
This seems like quite a lot of effort to go through, especially
considering the number of people working on Bazaar at the moment
The low change rate does mean there are not a lot of changes
to backport so it might not be a problem at the moment. If this picks
up, it might not be tenable.

> 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.
We've been doing this in Bazaar for a long time; there are various
places where we fall back to replacement code if the version of Python
in use doesn't provide certain utility functions.

This works well for e.g. missing library functions. It's harder to
provide compatibility for some other features, e.g. bytes/unicode
behaviour - you essentially end up inventing a third language that is
compatible with both Python2 and Python3 and you need to be
disciplined about what features you use so that they work in both the
old (2.6) and new world.

> This period (python release general availability/wide adoption) sounds
> like it should be more than 2 years.  Do you think 4 years is
> reasonable?
I don't think it should be a specific time period. Rather, it
should depend on what distributions you want to support and how many
users are affected.

> 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.
This seems like a reasonable approach.

Cheers,

Jelmer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20150906/35fc2227/attachment.pgp>