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.