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 _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
