No offense intended, but I think that using `2to3` at release time is exactly the wrong way around. I'd rather like to have something like `3to2`.
The idea is to use `2to3` only initially to move your code to Python3. From then on, develop your code in Python3 – that's what "we all" want, don't we? At release time, use `3to2` to also provide a Python2 version.
It is definitely not the recommended nor the common way of doing it. Many projects use 2to3 at release time (which hopefully include testing time) to support python 3.x. Numpy and scipy do exactly that for example, and we won't limit ourselves to python 3.x anytime soon.
The context I was speaking is projects who still want to support 2.x, which is what most projects want.
Obviously, if you don't care about supporting 2.x at all once the conversion is done, modifying the output and using the output as your reference source is fine.
> The context I was speaking is projects who still want to support 2.x
This is also what I was speaking about. And to reach that goal, you have generally 3 options:
1) write code that works with Python2 as well as Python3
2) maintain your code in Python2 and use 2to3 on release time
3) maintain your code in Python3 and use 3to2 on release time
Given you don't want to do 1) for whatever reason, my argument is that 3) seems to be the preferable solution. It allows you to use our loved Python3 right now, while still supporting Python2.
However, "in the wild" we see 2) way more often, and I don't understand why this is the case.
Because for many contributors, python 3 is not usable as there are so few packages available. And on the other hand, the improvements from python 2 -> 3 are really minor.
"No offense intended, but I think that using `2to3` at release time is exactly the wrong way around."
It's not a method I'd recommend, but I was just pointing out that some people had such success with 2to3 that it's reliable enough for them to provide releases based on it. I would guess that this isn't their eternal 3.x support plan, but may give some confidence in projects that 3.x is only a 2to3 run away.
As the name implies, 2to3 gets you from 2 to 3, but it leaves 2 behind entirely which isn't something most people are ready to do (myself included). I'm a fan of trying to run a single codebase that supports 2 and 3, so the method I like is to run 2to3 up front but don't immediately apply the patch it generates. Use that patch as a guide for the area that needs attention, then manually apply changes where the patch points you to and ensure they will work for both versions.
For example, 2to3 changes "print 'hello'" to "print('hello')", but if you need to support 2.4-3.2, you'll need something like "sys.stdout.write('hello')". Even supporting 2.7-3.2, 2to3 will make the same suggestion, but I would add "from future import print_function" at the top in order to function across both versions.
The same goes for imports. "import ConfigParser" will be changed to "import configparser", but what in my case I want...
try:
import configparser
except ImportError:
import ConfigParser as configparser
I've never had much difficulty in porting using this method. It's more work than creating a 3.x branch for your product and just letting 2to3 apply its changes there, but then you have the ongoing maintenance of two separate branches.
The idea is to use `2to3` only initially to move your code to Python3. From then on, develop your code in Python3 – that's what "we all" want, don't we? At release time, use `3to2` to also provide a Python2 version.