[Python-Dev] Language Summit Follow-Up

[Nick Coghlan]

On 31 May 2014 08:42, "Guido van Rossum" <guido at 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 at pitrou.net>
wrote:
>>
>> On Wed, 28 May 2014 15:26:38 -0700
>> Glyph Lefkowitz <glyph at 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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140531/67faf9b1/attachment.html>