[Python-Dev] Language Summit Follow-Up

[Glyph Lefkowitz]

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:

Library maintainers have a rapidly expanding matrix that requires an increasing number of branches to satisfy.
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+.

Add ensurepip to the installers.  Having pip reliably available increases the availability of libraries that help with porting, and will generally strengthen the broader ecosystem in the (increasingly long) transition period.
Add some warnings about python 3 compatibility.
It should at least be possible to get a warning for every single implicit string coercion.
Old-style classes.
Old-style division.
Print statements.
Old-style exception syntax.
buffer().
bytes(memoryview(b'abc'))
Importing old locations from the stdlib (see point 4.)
Long integer syntax.
Use of variables beyond the lifetime of an 'except Exception as e' block or a list comprehension.
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.
Add aliases for the renamed modules in the stdlib.  This will allow people to "just write python 3" in a lot more circumstances.
(re-)Enable warnings by default, including enabling -3 warnings.  Right now all warnings are silent by default, which greatly reduces discoverability of future compatibility issues.  I hope it's not controversial to say that most new Python code is still being written against Python 2.7 today; if people are writing that code in such a way that it's not 3-friendly, it should be a more immediately noticeable issue.
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.
Add a new 'bytes' type that actually behaves like the Python 3 bytes type (bytes(5)).

We have rejected any changes for Python 3.5, simply because of the extremely long time to get those features into users hands.  Any changes for Python 3 that we're proposing would need to get into a 3.4.x release, so that, for example, they can make their way into Ubuntu 14.04 LTS.

Here are some ideas for Python 3.4.x:

Usage of Python2 style syntax (for example, a print statement) or stdlib module names (for example, 'import urllib2') should result in a specific, informative warning, not a generic SyntaxError/ImportError.  This will really help new users.
Add 'unicode' back as an alias for 'str'.  Just today I was writing some documentation where I had to resort to some awkward encoding tricks just to get a bytes object out without explaining the whole 2/3 dichotomy in some unrelated prose.

We'd like to thank all the individuals who gave input and feedback in creating this list.

-glyph & Alex Gaynor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140528/9446de55/attachment-0001.html>