increasing the python requirement (was Re: [rfc] upgrade pqm chroot to lucid)

[jbowtie at amathaine.com]

On Thu, Jan 6, 2011 at 6:50 PM, Martin Pool <mbp at canonical.com> wrote:
>
> That seems to imply you think it will actually be infeasible or too
> hard to run through 2to3 if we keep compatibility with 2.4?
>

Well, 2.6 is intended as the baseline. Things like dict.has_key()
don't even exist in 3.x, whereas it's pretty common to find in 2.4 and
even 2.5 codebases.

There was a thread some months ago pointing out some of the issues;
off the top of my head 2to3 for example will complain about not using
hashlib, we won't be able to explicitly mark bytestrings (ie, use
bytes() or b''), etc.
Plus there a a heap of changes in the standard library that need to be
accounted for (say, the introduction the ssl module which might clear
up some of our transport code or the dropping of the md5 and sha
modules which might affect authentication code). Some of those just
won't go across since deprecated modules are dropped completely in the
3.x library.

The recommended transition strategy is, roughly:

# Port your code to Python 2.6.
# Make sure all the tests pass using that version.
# Run your code under Python 2.6 with the -3 flag.
# Fix any warnings.
# Run the tests again (still under Python 2.6).
# Run the 2to3 tool.
# Run your tests under Python 3.
# Fix any problems.
# Repeat until all tests pass.

The main point for maintenance is to only write Python 2.6 code and
use 2to3 to generate a 3.x version as part of the build process. You
don't really need to create a 3.x fork until such time as you decide
to abandon Python 2.x entirely.