2to3 is poorly named. With different fixers it is a fine tool for converting 2-only code to 2-and-3 straddling code. Even when using six, you need to do things like convert print statements to print() calls with future import, use 'as' in except clauses, and so on.


On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 28 May 2014 15:26:38 -0700
Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
> Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem.  A robust Tulip ecosystem requires the participation of people who are not yet using Python 3.

I was wondering whether you were trolling or not on this one.
>From a quality assurance point of view, adding major features to a
bugfix branch is extremely destructive, so I'm strongly -1 on it.

> Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation.  More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique <https://docs.python.org/3/howto/pyporting.html> mentions is still 2to3.

2to3 is certainly fine if you are porting to 3.x without looking to
keep your code 2.x-compatible. Until there's a better alternative, of
course.
So what we should do is better explain the choice (if you want to port
your code to 3.x, use 2to3; if you want to maintain dual-compatible
code, use six or something similar).

Regards

Antoine.



--
--Guido van Rossum (python.org/~guido)