On 31 May 2014 08:42, "Guido van Rossum" <guido@python.org> wrote:
>
> 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.

Both modernize & futurize build on lib2to3 to do the heavy lifting - they don't reinvent that wheel, they just change which fixes are applied by default and add a few more of their own.

However, even if going straight to Python 3, I suspect folks would still be better off doing something like:

* futurize --stage1 (migrates to 2.6+, but adds no new runtime dependencies - the output should be fairly idiomatic Python 2.6/7 code)
* 2to3 (wholesale migration to Python 3)

The trick, though, is that the granularity of that approach is at the process level - the entire application must be converted at once. You also can't start your own migration until all your dependencies are available in Python 3.

By contrast, migration via the common subset can be incremental and opportunistic:

* the granularity of migration is individual modules, rather than entire processes, so you can make a low risk gradual transition, even without a comprehensive regression test suite
* you initially stay on Python 2, so you can start whenever is convenient for you, rather than having to wait for all your dependencies

Cheers,
Nick.

>
>
> 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.
>>
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev

> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>