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
Thanks for for putting this together. On Wed, May 28, 2014 at 4:26 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.
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
On Wed, May 28, 2014, at 15:26, Glyph Lefkowitz wrote:
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.
Fun fact: This can be achieved with the -Qwarn command line option.
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. :)
I've did it. https://github.com/PyMySQL/mysqlclient-python https://pypi.python.org/pypi/mysqlclient -- INADA Naoki <songofacandy@gmail.com>
On 5/29/2014 1:22 AM, INADA Naoki wrote:
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. :)
I've did it.
https://github.com/PyMySQL/mysqlclient-python https://pypi.python.org/pypi/mysqlclient
I don't think that most people interpret Programming Language :: Python as indicating support for Python 3. So I suggest adding Programming Language :: Python :: 3 or even the more specific 3.3 and 3.4 -- Terry Jan Reedy
On 29 May 2014 08:26, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote: Thanks for the write-up!
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.
Agreed on this one - I only dropped it from 453 because I didn't think I could continue to push for it and still make the beta deadline for 3.4, not because I changed my mind. This mainly needs a champion to write the PEP to describe the exact details of what would be backported (the tricky parts of PEP 453 relating to pyvenv don't apply) and to actually do the work. Bundling the Python Launcher with the Windows installer would also be desirable.
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.
A few more for the "missing -3 warning" list: - calling str.encode - calling unicode.decode - returning str from str.decode - returning unicode from unicode.encode The relevant TypeErrors in 3.x show where the latter two warnings need to go in 2.7. More controversially: warn for any calls to Py2 str methods that aren't present on Py3 bytes.
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.
Given that the target audience here is our more conservative user base, Tulip/Trollius backends for Twisted and gevent seem more conducive to that than supporting Tulip's native coroutine syntax. That said, it's a pure additive change without any significant backwards compatibility implications, so I personally wouldn't object if Guido said yes.
Add aliases for the renamed modules in the stdlib. This will allow people to "just write python 3" in a lot more circumstances.
This is what the module aliasing options provided by python-future are designed to do - it's much closer to "just write Python 3" than six is (although that comes at the price of being a bit more magical). The python-future experience also shows there's a potential backwards compatibility issue here - depending on exactly how you do it, you can end up conflicting with other libraries trying to do the same thing.
(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.
The reasons these were turned off haven't changed, and passing -3 already enables DeprecationWarnings generally (along with -Qwarn). However, several of the warnings mentioned in the list above are currently missing entirely, so they won't show up regardless of the warning state.
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.
+1, although I think python-future provides a better "subset language" experience than modernize+six does, and provides a 3->common subset converter in addition to a 2->common subset (see http://python-future.org/faq.html#relationship-between-python-future-and-oth... for more on the difference between the two approaches). The futurize script also has the nice property of supporting two different stages, with "--stage1" being a pure syntactic update - no new runtime dependencies needed. "Big bang" migrations are highly unlikely to be the right choice for anyone, and while the code produced by python-future will still have some quirks (e.g. avoiding direct use of any mapping methods as PEP 469 ended up recommending, plus a bunch of import noise at the start of the file)
Add a new 'bytes' type that actually behaves like the Python 3 bytes type (bytes(5)).
This is available in python-future.
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.
While I realise it's out of scope for your "near term changes" list, there are still a few changes I think are worth exploring for the Python 3.5+ time frame: - the return of binary interpolation is already approved (but isn't implemented yet) - various other improvements to the Py3 binary data model (such as the ideas in PEP 467) - PEP 432 (cleaning up the startup sequence), or something along those lines, has now been identified as a prerequisite for decoupling Python 3 from the locale encoding on Linux (and hence letting us more easily ignore the entirely-inappropriate-for-the-21st-century C locale) - I'd like to see someone take a serious tilt at proposing "NAME <args>" call statement support at the language level. IPython already supports that style of invocation for arbitrary callables (so print statements still appear work even in Python 3 if you use IPython rather than the default REPL or direct script execution), and there's a proof of concept patch at http://bugs.python.org/issue18788 that shows CPython's parser is able to handle the idea (see my final comment for additional restrictions a full proposal would need) For that last point, my interest is as much educational as it is in easing the transition from Python 2. The parentheses in "print('Hello world!')" mean introducing the idea of function calls early to explain how it works, while being able to omit them makes it easier to gloss over the distinction between statements and function calls initially and then cover it later after the basics of flow control have been nailed down. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
For that last point, my interest is as much educational as it is in easing the transition from Python 2. The parentheses in "print('Hello world!')" mean introducing the idea of function calls early to explain how it works, while being able to omit them makes it easier to gloss over the distinction between statements and function calls initially and then cover it later after the basics of flow control have been nailed down.
I've been doing a lot of intro-to-python teaching lately (py2 so far...), and I understand this desire. IN fact, a lot of notes point to the fact that python's "hello world" is simply : print "hello world", rather than what is required in some languages to do something that simple. However, I also believe that when teaching it's better to introduce the "right way" to do something up front, rather than a "beginners' way", then later say, well, you really SHOULD do it this other way... So if we want our students to use print as a function, we might a well start them off that way. Saying that their very first easy program is: print("hello world") is fine -- they don't have to know or understand what a function call is -- they simply copy the syntax. And frankly, we get to simple function calls, VERY early in the program -- you can't really do anything without them... In fact, in my latest class, we've made an effort to introduce forward-thinking up front, even before we explain quite what it all means: use u"a string" to make a string you write a class like: class C(object): ... before we talk about subclassing, or what "object" is... just my $0.02 -Chris
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ 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/chris.barker%40noaa.gov
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 05/30/2014 09:46 AM, Chris Barker wrote:
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan wrote:
For that last point, my interest is as much educational as it is in easing the transition from Python 2. The parentheses in "print('Hello world!')" mean introducing the idea of function calls early to explain how it works, while being able to omit them makes it easier to gloss over the distinction between statements and function calls initially and then cover it later after the basics of flow control have been nailed down.
However, I also believe that when teaching it's better to introduce the "right way" to do something up front, rather than a "beginners' way", then later say, well, you really SHOULD do it this other way...
+1 Function calls are not that hard to understand. Anybody who has ever asked someone to do something for them should have a basic grasp of the nature of a function call. -- ~Ethan~
However, I also believe that when teaching it's better to introduce the "right way" to do something up front, rather than a "beginners' way", then later say, well, you really SHOULD do it this other way... So if we want our students to use print as a function, we might a well start them off
On 31 May 2014 02:47, "Chris Barker" <chris.barker@noaa.gov> wrote: that way. Saying that their very first easy program is:
print("hello world")
is fine -- they don't have to know or understand what a function call is
-- they simply copy the syntax. And frankly, we get to simple function calls, VERY early in the program -- you can't really do anything without them... OK, that's a fair criticism of that particular argument, so I'll stop using it. There are others, though: * improve consistency between IPython's existing implied call support and vanilla Python 3.5+ * retroactively make a lot of Python 2 examples also valid for Python 3.5+ * ease the migration to Python 3 for ad hoc utility scripts (which often use print heavily) * reduce the syntactic noise in migration patches (although large applications tend to use print less than scripts do) * largely eliminate one of the *human* barriers to migration from Python 2 (forgetting the parens for print at the interactive console and in ad hoc scripts) I already have too many other things on my todo list to work this up into a full PEP, but the proof of concept (along with IPython's existing support) shows there's no *technical* barrier to adding the feature. It's a question of whether or not we *want* to blur the boundary between simple statements and simple imperative function calls like that. Cheers, Nick.
On Fri, May 30, 2014 at 7:05 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I already have too many other things on my todo list to work this up into a full PEP, but the proof of concept (along with IPython's existing support) shows there's no *technical* barrier to adding the feature.
That doesn't follow. A PoC and even IPython can ignore all kinds of *technical* issues (e.g. giving code that's valid today a different meaning). Please drop this idea or at least take it out of this thread and focus on what *can* and *should* be done, in particular adding warnings with good hints about what went wrong when Python 3 encounters what appears to be a print statement. -- --Guido van Rossum (python.org/~guido)
Chris Barker writes:
that way. Saying that their very first easy program is:
print("hello world")
is fine
I have had similar experience on a small scale. Also I've been teaching R recently. The students who know Python (Python 3, we don't have backward compatibility issues in our work) got the concept that all "real work" in R is done by functions, immediately. Those who don't, have trouble with the concept that "help" and "q" (for "quit") need parentheses to get them to work. Unfortunately R doesn't have Python's Easter Eggs, so they get a code dump rather than help when they type the bare names.
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)?
On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote:
I hope it's not controversial to say that most new Python code is still being written against Python 2.7 today;
Given that Python 3 downloads now outnumber Python 2 downloads, I think 'most' might be an overstatement. But I think it a moot point.
if people are writing that code in such a way that it's not 3-friendly, it should be a more immediately noticeable issue.
If the truth were, conservatively, 1/4 of new Python code in 2.7, or even less, I would still be in favor of making 3-friendly 2.7 code easier. This is also important for the separate codebase approach, as in the stdlib. Just last week, I got a rejected chunk when backporting because a 2.7 idlelib module uses 'file(...' instead of 'open(...'. -- Terry Jan Reedy
On Thu, May 29, 2014 at 9:30 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote:
I hope it's
not controversial to say that most new Python code is still being written against Python 2.7 today;
Given that Python 3 downloads now outnumber Python 2 downloads, I think 'most' might be an overstatement. But I think it a moot point.
How can you determine that Python3 downloads actually outnumber Python2 downloads? It seems that looking at Windows downloads (as I saw in a thread earlier this month) is fallacious at absolute best. Linux and OSX both ship with Python2, and most downloads happen via individual package management tools. Even including Python3.4 as a default Python3 doesn't mean that it's the default Python on the system.
From my perspective as an engineer and library maintainer: Pypi seems to indicate an overwhelming number of Python2 usage, and so do the job requisitions that I've seen. Furthermore, even Python based libraries for cutting edge technologies are still written in Python2 and later converted to Python3. I just don't understand how we (as a community) can make the assertion that most "new Python" is written in Python 3.
What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. -Mark
On Sat, May 31, 2014 at 3:40 AM, Mark Roberts <wizzat@gmail.com> wrote:
What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3.
That's of absolutely ZERO value to anyone who has to maintain support for Python 2.3 or even 2.7. Will this hypothetical 2.8 run, unchanged, all code written for 2.7? If not, all you've done is add a third branch to maintain, and solved nothing; and if it will, how much can you really change? ChrisA
On 30/05/2014 18:40, Mark Roberts wrote:
What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3.
-Mark
What is the point of flogging a horse that's been dead for so long that it's already down to a skeleton? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
On 31 May 2014 03:42, "Mark Roberts" <wizzat@gmail.com> wrote:
What I'd really like to see is a Python 2.8 that makes sufficient changes
to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. That's what projects like python-future are for. Python 2.8 wouldn't help, since most folks still target 2.6 for compatibility with stable Linux platforms like RHEL, CentOS, Debian Stable & Ubuntu LTS. This is a key point folks often miss in these discussions: even putting Python 3 aside entirely, the migration of the overall ecosystem from Python 2.6 to Python *2.7* is not yet finished. RHEL 7 (which uses 2.7 as the system Python) is currently only available as a release candidate, and the same necessarily holds true for its downstream rebuilds like CentOS. We saw this happen with Python 2.4 as well: for a lot of library developers, the day CentOS 6 finally landed (with Python 2.6 as the system Python) was the day they finally decided to drop support for Python 2.4. It's that slow adoption cycle for new feature releases *within* the Python 2 series that means the effort that would be needed to create a Python 2.8 release is better put into tools and utilities that people can use *now* (like PyPI backports of standard library modules, python-future and the "pymigrate" utility Steve Dower suggested and Eric Snow has started working on), tweaks to 2.7 itself (like PEP 466 and a possible future backport of the ensurepip changes) and Python 3 changes that improve both Python 3 *and* the subset it shares with Python 2 (like the restoration of binary interpolation support approved for 3.5). Cheers, Nick. P.S. I've written more about adoption cycles for new Python versions at http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_an...
On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz <glyph@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.
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. On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou <solipsis@pitrou.net> 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
On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote: 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)
On 31 May 2014 08:42, "Guido van Rossum" <guido@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@pitrou.net>
On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Backport 'yield from' to allow people to use Tulip and
Tulip-compatible code, and to facilitate the development of Tulip-friendly
wrote: 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
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 <ncoghlan@gmail.com> wrote:
On 31 May 2014 08:42, "Guido van Rossum" <guido@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@pitrou.net>
On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Backport 'yield from' to allow people to use Tulip and
Tulip-compatible code, and to facilitate the development of Tulip-friendly
wrote: 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)
participants (15)
-
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Chris Angelico -
Chris Barker -
Eric Snow -
Ethan Furman -
Glyph Lefkowitz -
Guido van Rossum -
INADA Naoki -
Mark Lawrence -
Mark Roberts -
Nick Coghlan -
Stephen J. Turnbull -
Terry Reedy