Switching to Python 3

[Nick Coghlan]

On 08/04/2012 02:19 AM, Toshio Kuratomi wrote:
> I suggest that you start by asking nicely what things need to be done to
> port those things to python2 and then go to work on doing them.  Trying to
> force a change via the Feature process is reversing the order of things.
> Features don't exist to force other people to do work.  Features exist to
> showcase and coordinate the work that you are doing.

Right. Since I know Barry Warsaw, I got to see a bit of the way the
Ubuntu/Canonical folks went about this, and one of the big things they
did was to work with upstream projects to add Python 3 support. (e.g.
the dbus-python patches for Python 3 compatibility were mostly Barry's
work:
http://www.wefearchange.org/2011/12/lessons-in-porting-to-python-3.html)

> One thing to watch out for is that once you start porting applications, the
> live images and install dvds will start requiring python3.  If you aren't
> careful, some releases may end up requiring both python2 and python3.  This
> is something that would need to be coordinated with the spins as well as the
> applications you're porting to figure out what is okay as a size constraint.
> You may end up having to maintain a parallel python3 branch for many
> applications until all of the applications on an image are ported to
> python3.

Wherever possible, it's *much* easier to go with a single codebase that
runs on both Python 2 and Python 3. The common subset of the two
variants ended up being much larger than originally expected. For pure
Python code, Armin Ronacher's "python-modernize" can help flush out
legacy constructs that will fail under Python 3.

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Infrastructure Engineering & Development, Brisbane