Porting to Python 3: Do’s and Don’ts
So. Python 3 is here and everybody is happy. Now the community expects everyone who wrote a library to port it over to Python 3. So here my experiences so far:
Don'ts
Let's start with the things you should not do.
- Use py.test for your testsuite. The developers told me that they do not plan to adapt it to Python 3 in the near future. That however is a gib no-go for such a library because it automatically breaks all the libraries that use it for unittesting. So switch over to unittest or nose as soon as possible. I'm not exactly sure how compatible nose is with Python 3, but I will post a followup about that issue in the following days because nearly all the testsuites of my libraries are currently written in py.test and nose is the testsuite that comes the closest.
- Forking your library for Python 3. Don't do that. If you can't create a version that comes out of 2to3 and passes your testsuite do not try to hand correct the code generated. Keep in mind that you will have to support both 2.x and 3.x for at least the next two years so hand correcting the 3.x version is nothing you want to do. If you have problems with 2to3 (because it does something wrong) write it to the python-porting mailinglist.
- Drop 2.5 support. I know converting libraries is easier if you can just support 2.6 and 3.0 but until Linux distributions / OS X ship up to date Python versions it will take some time. You will only hurt your users with such a decision.
Dos
Now to what you should do
- Report problems with 2to3 as soon as possible and suggest improvements. From what I saw so far 2to3 is a nice tool but it needs a lot of post-converting fixes which are unacceptable. Try to port your library and think of how you could give 2to3 hints what it should do. I guess we can expect more command line switches, custom fixes or even comments that give 2to3 an idea of what to do (similar to how pylint ignores warnings). Write that to the porting mailinglist as soon as possible or inform “gutworth” on irc.freenode.net/
#python-devwho is maintaining the 2to3 tool.
That's it for the moment. Concrete tips for porting specific idoms over will come once that is possible :)
I guess your third "don't" could be extended to "Don'ts: Drop 2.4 support" For the same reason to no drop 2.5 support. For a library I do I notice about 45% 2.4 and 45% 2.5 downloads (eggs). Rather ugly but I guess not that bad either.
— Christof on Sunday, December 7, 2008 12:36 #
If you can support 2.5, you can support 2.4 as well. But that's a good point :)
— Armin Ronacher on Sunday, December 7, 2008 13:05 #
If you want to know who I really am, it's Benjamin Peterson. :)
— "gutworth" on Monday, December 8, 2008 3:50 #
What about Python 2.3!? Just kidding. I should be upgraded to 2.5 when Python 2.7 comes out.
— smokey on Monday, December 8, 2008 9:50 #
Let's hope the Debian guys and contributors get that (currently increasing) bunch of release-critical bugs in Lenny fixed, so Python 2.6 will enter the Debian arena. It think it will be the next base Python version in the next cycle as opposed to 3.0 as it makes for a slighter (probably still not too easy) transition. And while `python3` is at least in the Ubuntu repos, it's still missing in Debian. Go, Lenny, go!
— Jochen Kupperschmidt on Monday, December 8, 2008 23:29 #
Only found your post now. regarding py.test and python3000 - i actually want to work on supporting Python3000. I really want it to work on virtually all python interpreters and versions - currently it's tested on version 2.4 till 2.6 and on cpython/pypy .I don't think there is much preventing it to work with py3 and i think it still works fine with 2.3 as well.
— holger krekel on Wednesday, April 8, 2009 14:09 #
A note for posterity:
The first "don't" is no longer needed -- py.test works fine with Python3. This makes me very glad; writing unit tests is enough of a chore without unittest's Java-style API and lack of magical niceties.
— Paul on Friday, January 8, 2010 18:34 #