What's the preferred method in the community for having python 2.x and 3.x in the same codebase?

I am starting a project in Python 3.x, (I'm quite new to Python) and there exists the possibility that I will need to use say Thrift or any other library that is not yet ported to Python 3.x.

I don't mind about devoting some (substantial) amount of time to convert an external library to Python 3.x if with that others can benefit from that, but I'm curious if t开发者_JS百科here's any preferred way in the Open Source community to deal with this problem.

I have been reading here and there in the python.org site and in some other websites, but I haven't found anything conclusive. The only thing that I found is that this is a chicken-and-egg problem.

It's out of the question (unless there's no other option) that I ship a dump of a library with my own modifications just to make it 3.x compliant.

Should I...

1. prepare all the code with __future imports and change here and there appropriately and leave it ready to work with both 2.x and 3.x? Am I going to find any problem with this, other than the natural resistance of upstream to integrate such amount of changes?

2. create another branch of the code? That, to me, should be quite useless, as nobody will maintain that branch except me, probably, and it's a huge duplication effort.

3. use some type of wrapper that I am not aware of to use those libraries as-is (like using some intermediate bindings in another language) and just create the glue in my code?

Many thanks!

There are various strategies you can use, and which is best depends on several things, like what you are porting, how complex it is and how much of Pythons internals it uses.Basically, if you want to support both Python 2 and Python 3 at one time, run 2to3 on your code, and see how much it changes. If the changes are mostly such things that you can solve with __future__ imports, then porting to Python 3 and the reintroducing Python 2 compatibility may be a feasible way forward. (For an in-depth look at this, see my Migration strategies page.)

If the changes are major, you are probably better off using 2to3 to support Python 3. This is made easier if you can use Distribute for packaging your project.

In both cases you may have use of six.

See also my talk on the subject.

I suggest supporting Python 2.x and Python 3.x simultaneously from the same code base, using tox. Check out the Supporting All Versions of Python All The Time With Tox talk from Pycon 2011.

I Can't talk for the community but these from __future__ import ... don't work for all python versions or aren't reliable on some cases.

print_function and unicode_literals were added on Python2.6, with_statement on Python2.5 and the others on Python2.2

So, if you want to support 2.6 or later, you're fine. If you still need to support 2.5 or, even worst, 2.4, you will need another approach.

Using from __future__ import unicode_literals won't work properly because Python2 let you do conversion from byte to unicode without encoding while Python3 don't. Also, calling str or bytes has different arguments.

The difference of treatment on strings seems to be the main problem to make a program compatible with both Python2 and Python3.

The approach I've been using is to maintain the code in version 2 format, use the 2to3 converter, and test the output in version 3. If there are errors with the generated version 3 code, I work with the version 2 code to get a better conversion until it works. The Python wiki has some good advice on this: http://wiki.python.org/moin/Python2orPython3

PEP 3000 also has some good advice on maintaining a dual-version codebase.

When your library is finally 3.x-ready, (maybe doing it yourself) then you have a 3.x codebase ready to go.

http://docs.python.org/dev/howto/pyporting.html is the source for the most up-to-date advice from the CPython core devs (although it sounds like you have already looked at that).