On Wed May 28 2014 at 10:14:39 PM, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
At the language summit, Alex and I volunteered to put together some recommendations on what changes could be made to Python (the language) in order to facilitate a smoother transition from Python 2 to Python 3.  One of the things that motivated this was the (surprising, to us) consideration that features like ensurepip might be added to the future versions of the 2.7 installers from python.org.

The specific motivations for writing this are:

  1. Library maintainers have a rapidly expanding matrix that requires an increasing number of branches to satisfy.
  2. People with large corporate codebases absolutely cannot port all at once.

If you don't have perfect test coverage then you can't make any progress.  So these changes are intended to make porting from python 2 to python 3 more guided and incremental.  We believe that these attributes are necessary.

We would like to stress that we don't believe anything on this list is as important as the continuing efforts that everyone in the broader ecosystem is making.  If you just want to ease the transition by working on anything at all, the best use of your time right now is porting https://warehouse.python.org/project/MySQL-python/ to Python 3. :)

Nevertheless there are some things that the language and CPython could do.

Unfortunately we had to reject any proposal that involved new __future__ imports, since unknown __future__ imports are un-catchable SyntaxErrors.

Here are some ideas for Python 2.7+.
[SNIP] 
  1. 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.  We should replace 2to3 with something like <https://github.com/mitsuhiko/python-modernize>. 2to3 breaks your code on python 2, and doesn't necessarily get it running on python 3.  A more conservative approach that reduced the amount of work to get your code 2/3 compatible but was careful to leave everything working would be a lot more effective.

Two things. One is the HOWTO mentions 2to3 only when you are dropping Python 3 support and since that makes your life the easiest it's listed as the first option. You will notice point 2 in the TL;DR is be source compatible if keeping Python 2 compatibility. The main part of the doc is also all about source compatibility and using 2to3 while maintaining compatibility is relegated to the Alternatives section at the end (heck, 2to3 is mentioned only 3 times in that entire document, one of which is in a code comment).

Two, is how do you see python-future fit into this (I know others have brought it up but we have two different approaches now to keeping source compatibility that vary in magic and thus smoothing out edges)?