Thanks for for putting this together. On Wed, May 28, 2014 at 4:26 PM, Glyph Lefkowitz <gl...@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.
One of the parallel discussions that came out of the language summit centers on basically the same idea: https://mail.python.org/pipermail/python-dev/2014-April/133986.html The key points are that there would be a separate tool that wraps the 2.7 interpreter and enforces the 2.7/3.x subset language but only for source files that have are tagged (a la the coding cookie). So there would be no need to make changes to Python itself. Some have also suggested this could also be accomplished via a pylint plugin. I'm working on an implementation called (for now) "pymigrate" that should eventually be available via the cheeseshop. A lot of what you've written here is really useful. > Here are some ideas for Python 2.7+. > > 1. 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. My understanding is that this is already the plan. > 2. Add some warnings about python 3 compatibility. > > 1. It should at least be possible to get a warning for every single > implicit > string coercion. > 2. Old-style classes. > 3. Old-style division. > 4. Print statements. > 5. Old-style exception syntax. > 6. buffer(). > 7. bytes(memoryview(b'abc')) > 8. Importing old locations from the stdlib (see point 4.) > 9. Long integer syntax. > 10. Use of variables beyond the lifetime of an 'except Exception as e' > block or > a list comprehension. +1 to improving the coverage of the -3 option in 2.7. > > 3. 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. What about Trellis? Regardless, adding yield from to 2.7 is going to be a tough sell. > 4. Add aliases for the renamed modules in the stdlib. This will allow people > to "just write python 3" in a lot more circumstances. I like this, but it seems to me to be a better fit for something like six or even pymigrate. > 5. (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. This is also something that fits better with a separate tool. > 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 Good luck with that one! <wink> -eric _______________________________________________ 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
