Breaking python2.4 compatibility for bzr-2.4

[Barry Warsaw]

On Apr 21, 2011, at 11:07 AM, Martin Pool wrote:

>I hear really mixed messages about when distributions may start
>switching to 3.0 by default: in Ubuntu, people have floated the idea
>of dropping 2.x support as early as Oneiric (late this year) and as
>late as never.

The way I'd put it is that Python3-by-default is a goal for Ubuntu, but likely
in the 12.04-14.04 LTS cycle.  For 11.10 and 12.04, we're going to see how far
we can get along that path, with the goal of only Python3 on the CD.

Python 2 won't go away, but may be moved to universe.  For Oneiric and thus
12.04 LTS, Ubuntu will drop Python 2.6, so Python 2.7 will be the only
officially supported Python 2.

>If that crystallizes into an actual deadline then people will start working
>on it.  Before that, it is just personal interest, or waiting for py3 to
>provide some really compelling benefit.
>
>I think it's still an open question whether dropping 2.4 will help
>with going to python3.  As I said in the earlier thread, if someone
>comes up with a patch that moves bzr (or even some nontrivial subset)
>to py3 compatibility, and they say that they found it too hard to do
>this without using py2.6 features, that would be a compelling reason
>to drop 2.4.  Some people on the web have said they found this to be
>the case in other projects, but other people say the opposite, so I
>don't put a lot of weight on it.

I know that there are people supporting Python 2.4 to 3.x in one code base,
but I think it's much more common that you'll see Python 2.6 to 3.x in a
single code base.

Using Python 2.6 as the lowest base line can provide lots of benefits for an
eventual move to Python 3.  For example, you can use __future__ imports to
start using the print() function, and to mark modules as unicode literal clean
(i.e. via 'from __future__ import unicode_literals).  You can also start to
mark your bytes literals with the b'' prefix.  Being absolutely, rock-solid
clear about what are bytes and what are strings is typically the most
difficult part of a Python 3 conversion.  I don't know bzr well enough, but I
suspect that bzr has to make that distinction all the time.  Python 2.6 will
help you make that distinction crystal clear in the code base.  You can also
take advantage of the -3 flag to warn about Python 3 incompatibilities.

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110421/fde683bb/attachment.pgp>