Right. The point is that the current HOWTO gives information that is not useful for most people who are tasked with a port.
On Fri, May 30, 2014 at 6:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > > On 31 May 2014 08:42, "Guido van Rossum" <gu...@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 <solip...@pitrou.net> > wrote: > >> > >> On Wed, 28 May 2014 15:26:38 -0700 > >> Glyph Lefkowitz <gl...@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 > > > > -- --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/archive%40mail-archive.com