Create Python 2.8 as a transition step to Python 3.x
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported. One of the most disruptive changes in Python 3 is the strict separation of bytes from unicode strings. Most of the other incompatible changes can be handled by 2to3. Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes. This could include: - print as function - default string literal as unicode - return view objects for dict.keys(), etc - rename modules in standard library - rename long to int - rename .next() to __next__() - accept only new 'raise' syntax - remove backticks for repr - rename unicode to str - removal of 'apply', 'buffer', 'callable', 'execfile' - exec as function - rename os.getcwdu() to os.getcwd() - remove dict.has_key - move intern to sys.intern() - rename xrange to range - remove xreadlines New features of Python 3.x could be backported if easy since they could be useful to entice developers to move from 2.7 to 2.8. Problems with this idea: - it would be a huge amount of work. There are thousands of commits to Python 3.x since it was branched. Most of them are not related to the above features but back porting them would still be a huge effort. I tried backport 'print' as a function just to get an idea of the work. - if people install this new version of Python as the default, old scripts and programs will break. I believe this breakage was the movation for making Python 3 an all-at-once jump. I'm not sure how to handle this, maybe this version could be used only by developers during their Python 3 porting efforts. Alternatively, only install it as 'python2.8', never 'python' or 'python2'. An alternative approach to producing Python 2.8 would be to start with the Python 3.x latest branch. Modify bytesobject and unicodeobject to have as close to Python 2 behavior as practical. A-journey-of-a-thousand-miles-begins-ly y'rs Neil
This thread just happened not three weeks ago. Python 2.8 ain't gonna happen. -- ~Ethan~
On Sat, Jan 18, 2014 at 2:22 PM, Neil Schemenauer <nas-python@arctrix.com> wrote:
- it would be a huge amount of work. There are thousands of commits to Python 3.x since it was branched. Most of them are not related to the above features but back porting them would still be a huge effort. I tried backport 'print' as a function just to get an idea of the work.
Guido's time machine strikes again. Put this at the top of your script and run it under 2.7 or 2.6: from __future__ import print_function ChrisA
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
One of the most disruptive changes in Python 3 is the strict separation of bytes from unicode strings. Most of the other incompatible changes can be handled by 2to3.
For many application areas, the text problem seems to have been somewhat solved, to the point where people are writing 2&3 code successfully.
Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes.
Various people have suggested versions of this idea. At one time, I could imagine it, even after PEP404. But a 2.8 project should have started soon after 2.7 was released with 2.8 released soon after 3.3 or certainly now with 3.4. I think it too late now.
This could include:
I believe you left out the int division change.
Problems with this idea:
People who cannot move to 3.x because of libraries could not move to 2.8 for the same reason. Over half of the most commonly downloaded libraries already have 3.x versions. Major linux distributions are already in the process of switching to 3.x as default Python.
- it would be a huge amount of work.
Yes, and the current volunteer pydev group will not do it. So this is literally the wrong forum. Martijn Faassen posted the following on python-list on the 6th. ''' I've started an informal channel "#python2.8" on freenode. It's to discuss the potential for a Python 2.8 version -- to see whether there is interest in it, what it could contain, how it could facilitate porting to Python 3, who would work on it, etc. If you are interested in constructive discussion about a Python 2.8, please join. I realize that if there is actual code created, and if it's not under the umbrella of the PSF, it couldn't be called "Python 2.8" due to trademark reasons. But that's premature - let's have some discussions first to see whether anything can happen. '''
There are thousands of commits to Python 3.x since it was branched. Most of them are not related to the above features but back porting them would still be a huge effort. I tried backport 'print' as a function just to get an idea of the work.
You are unusual. Many 2.8 advocates want it handed to them for free. -- Terry Jan Reedy
On 2014-01-18, Terry Reedy wrote:
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
For many application areas, the text problem seems to have been somewhat solved, to the point where people are writing 2&3 code successfully.
Sure you can write code that's compatible with 2&3, that's not the code I'm talking about. I'm talking about the millions (maybe billions) of lines of existing Python code.
I think it too late now.
I disagree. The amount of Python 2 code that exists exceeds the amount of Python 3 by orders of magnitude. That existing codebase either stops evolving and stays Python 2 forever or we do all that's practical to help people move it to a current version of Python.
I believe you left out the int division change.
That should be on the list.
People who cannot move to 3.x because of libraries could not move to 2.8 for the same reason. Over half of the most commonly downloaded libraries already have 3.x versions.
That's a necessary condition but the vast amount of existing Python 2 code has not been ported. Lots of it would be private libraries or applications. You only have to look at the download stats for the Python interpreter to confirm this.
I realize that if there is actual code created, and if it's not under the umbrella of the PSF, it couldn't be called "Python 2.8" due to trademark reasons.
I don't give a shit what it's called. A Python 2 fork is going to happen whether the PSF blesses it or not, I can't believe that's even a point of discussion. People are still maintaining Cobol compilers. Neil
On Sat, Jan 18, 2014 at 07:13:32PM -0600, Neil Schemenauer wrote:
On 2014-01-18, Terry Reedy wrote:
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
Why? If it isn't broken, don't break it. At last year's US PyCon, there was at least one person still using Python 1.5 in production. Doing so means that he gets no bug fixes or security updates for 1.5, but if he doesn't need them, that is no loss. Python 2.7 will almost certainly still be supported by (for example) Red Hat until 2023, which is probably longer than most applications will be still in use.
For many application areas, the text problem seems to have been somewhat solved, to the point where people are writing 2&3 code successfully.
Sure you can write code that's compatible with 2&3, that's not the code I'm talking about. I'm talking about the millions (maybe billions) of lines of existing Python code.
I think it too late now.
I disagree. The amount of Python 2 code that exists exceeds the amount of Python 3 by orders of magnitude. That existing codebase either stops evolving and stays Python 2 forever
Why is that a problem? Some people will never migrate away from Python 2.7/2.5/2.4/1.5. That's okay. A few months ago I ported an application from 2.3 to 2.6. It's not well recognised that Python 3 is not the first time Python broke backwards compatibility: string exceptions raise "This is an error" became a warning in 2.5 (I think) and a SyntaxError in 2.6. This application made extensive use of string exceptions. My customer was happy with 2.3 code for years, until they upgraded their server to a version of Centos with 2.6, and that was the only reason they upgraded. I expect they will stick with 2.6 until such time as they upgrade the server again in another decade or so, and that's fine. They may never upgrade, and that's fine too.
or we do all that's practical to help people move it to a current version of Python.
Define "all that's practical". How much hand-holding do they need? On the Python-Dev list, there are *hundreds* of emails about this issue, which is distracting the core devs from making Python 3 even more awesome. [...]
I don't give a shit what it's called. A Python 2 fork is going to happen whether the PSF blesses it or not
I doubt that. Stackless may try to call itself Python 2.8, but it won't be porting Python 3 features: https://mail.python.org/pipermail/python-dev/2013-November/130421.html Stackless wanted to release a 2.8, but it wouldn't contain any additional Py3 features: https://mail.python.org/pipermail/python-dev/2013-November/130421.html it would be a version bump to support a newer Microsoft compiler. There are plenty of people who *say* they want a Python 2.8 with half the Python 3 features, but nobody as far as I can see is actually willing to do the work. If they were, why haven't they started? They don't need permission. -- Steven
On 19 January 2014 12:04, Steven D'Aprano <steve@pearwood.info> wrote:
On Sat, Jan 18, 2014 at 07:13:32PM -0600, Neil Schemenauer wrote:
I disagree. The amount of Python 2 code that exists exceeds the amount of Python 3 by orders of magnitude. That existing codebase either stops evolving and stays Python 2 forever
Why is that a problem? Some people will never migrate away from Python 2.7/2.5/2.4/1.5. That's okay. A few months ago I ported an application from 2.3 to 2.6. It's not well recognised that Python 3 is not the first time Python broke backwards compatibility: string exceptions
raise "This is an error"
became a warning in 2.5 (I think) and a SyntaxError in 2.6. This application made extensive use of string exceptions. My customer was happy with 2.3 code for years, until they upgraded their server to a version of Centos with 2.6, and that was the only reason they upgraded. I expect they will stick with 2.6 until such time as they upgrade the server again in another decade or so, and that's fine. They may never upgrade, and that's fine too.
For anyone that ever travels by plane, it can be worth watching aircraft entertainment systems go through their boot cycle to see what they're running on (the difficulty of getting software, even entertainment software, approved to run on aircraft can make for very long lead times). The last one I checked was based on Red Hat 7.1, released in 2001 and unsupported for a very long time, but still entirely serviceable for that particular use case. Old doesn't always mean broken, sometimes it just annoys your developers to be asked to use such old and blunt tools when newer and sharper ones are available :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Neil Schemenauer <nas-python@arctrix.com> writes:
On 2014-01-18, Terry Reedy wrote:
For application code, why does it need to be ported [to Python 3].
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
Maintained by whom? The PSF will stop maintaining Python 2, yes. But that doesn't stop other parties – Red Hat, ActiveState, etc. – doing so for whatever customers are still interested in compensating them for their work. So long as the cost of getting the Python interpreter maintained by *someone* is lower than the perceived cost of porting to Python 3, the code doesn't need to be ported. This is a great and salient benefit of Python itself being free software: Unlike a non-free software platform, no recipient of a free-software Python is beholden to the vendor for ongoing maintenance. That point seems obvious to me. -- \ “It is the fundamental duty of the citizen to resist and to | `\ restrain the violence of the state.” —Noam Chomsky, 1971 | _o__) | Ben Finney
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-01-19, 03:58 GMT, you wrote:
But that doesn't stop other parties – Red Hat, ActiveState, etc. – doing so for whatever customers are still interested in compensating them for their work.
a) necessary disclaimer: I AM not speaking for my employer, just words out of my ass. b) The point which is overlooked here, that people promoting python 2.8 are not speaking for STABILITY in the sense RHEL is stable. They want further DEVELOPMENT and CHANGES of Python to improve and react to the changed circumstances. That is not, as far as I understand it, the business Red Hat is in. Our customers ask us to support Python 2.7.* (or 2.6.* for RHEL-6, and 2.4.* for RHEL-5) with API UNCHANGED as it is now so that their applications developed now for RHEL 7 (or RHEL 6, 5, etc.) are running UNCHANGED. They are usually NOT interested in further development and changing Python API. So, I don't see us as rooting for the further development of Python 2.* API. Best, Matěj -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iD8DBQFS3FLU4J/vJdlkhKwRAnrDAJ45gSeWpGolBz/REHg04JE1yoPSnACcD1cj Q6EMTVNt1iPe2/USm2vPxEk= =Pufw -----END PGP SIGNATURE-----
Matěj Cepl <mcepl@redhat.com> writes:
On 2014-01-19, 03:58 GMT, you wrote:
But that doesn't stop other parties – Red Hat, ActiveState, etc. – doing so for whatever customers are still interested in compensating them for their work.
a) necessary disclaimer: I AM not speaking for my employer, just words out of my ass. b) The point which is overlooked here, that people promoting python 2.8 are not speaking for STABILITY in the sense RHEL is stable. They want further DEVELOPMENT and CHANGES of Python to improve and react to the changed circumstances.
I'm not overlooking that, I'm pointing out that Python is free software, so *the option is there*, for those who want Python 2 maintained indefinitely, to motivate and compensate some party to do it. Python 2 is free software, so any capable party can fulfil the developer and maintainer role without any further permission required. The PSF has made it clear they will not be that party past a certain point; but Python 2 is licensed freely from the PSF to all recipients, so the PSF's decision not to maintain Python 2 in no way prevents anyone else doing so. So, what “people promoting the continuance of Python 2” are asking for is entirely within their power to have, if they want it enough. Will they do it? That's up to them; no-one is stopping them.
That is not, as far as I understand it, the business Red Hat is in.[…] So, I don't see us as rooting for the further development of Python 2.* API.
And that's an entirely reasonable decision for Red Hat to make. My point is that *nothing the PSF is doing prevents* such a party from choosing to do so. In other words, those who want Python 2 to continue need to either bite the bullet and move their migration to Python 3 forward, or get themselves organised and come up with an entity which will maintain Python 2 for as long as they want it maintained. It's no-one else's responsibility, and no-one else is stopping them. Put up or shut up, folks! -- \ “Software patents provide one more means of controlling access | `\ to information. They are the tool of choice for the internet | _o__) highwayman.” —Anthony Taylor | Ben Finney
On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote:
On 01/19/2014 03:35 PM, Ben Finney wrote:
In other words, those who want Python 2 to continue need to either bite the bullet and move their migration to Python 3 forward
Um, if they want Python 2 to continue, why would they migrate to Python 3?
Because you can't always get what you want. I want a pony, but since I can't afford one or have any place to keep it, I've made do without. -- Steven
On Sun, Jan 19, 2014 at 4:06 PM, Steven D'Aprano <steve@pearwood.info>wrote:
On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote:
On 01/19/2014 03:35 PM, Ben Finney wrote:
In other words, those who want Python 2 to continue need to either bite the bullet and move their migration to Python 3 forward
Um, if they want Python 2 to continue, why would they migrate to Python 3?
Because you can't always get what you want. I want a pony, but since I can't afford one or have any place to keep it, I've made do without.
I think the odds of Python getting from __future__ import pony are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have: from __future__ import everything since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add: range = xrange --- Bruce
On 2014-01-20 03:40, Bruce Leban wrote:
On Sun, Jan 19, 2014 at 4:06 PM, Steven D'Aprano <steve@pearwood.info <mailto:steve@pearwood.info>> wrote:
On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote: > On 01/19/2014 03:35 PM, Ben Finney wrote: > > > >In other words, those who want Python 2 to continue need to either bite > >the bullet and move their migration to Python 3 forward > > Um, if they want Python 2 to continue, why would they migrate to Python 3?
Because you can't always get what you want. I want a pony, but since I can't afford one or have any place to keep it, I've made do without.
I think the odds of Python getting
from __future__ import pony
are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:
from __future__ import everything
That should be: from __future__ import * although it would still be discouraged because you might find that you're no longer able to get at some of the stuff you have already. :-)
since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:
range = xrange
On Jan 19, 2014, at 19:40, Bruce Leban <bruce@leapyear.org> wrote:
On Sun, Jan 19, 2014 at 4:06 PM, Steven D'Aprano <steve@pearwood.info> wrote:
On Sun, Jan 19, 2014 at 03:44:32PM -0800, Ethan Furman wrote:
On 01/19/2014 03:35 PM, Ben Finney wrote:
In other words, those who want Python 2 to continue need to either bite the bullet and move their migration to Python 3 forward
Um, if they want Python 2 to continue, why would they migrate to Python 3?
Because you can't always get what you want. I want a pony, but since I can't afford one or have any place to keep it, I've made do without.
I think the odds of Python getting
from __future__ import pony
are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:
from __future__ import everything
If that existed, I wouldn't use it. Without it, I know my 2.6+/3.3+ code will work until 3.7. With it, if 3.5 added a new future feature, my code may only work until 3.4. That's not worth it for the convenience of saving a few characters.
since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:
range = xrange
There are only four live future features in 2.6 and 2.7, and you can fit them all into one statement that fits in 80 columns. Which you can put into your project template, and then you're done with it. And then I usually have one more line, "from sixify import *", where sixify is a project-specific collection of imports from six. (And then the challenge is fighting to stop people from putting non-six-related things into sixify and turning it into one of those "stdafx.h" messes that every windows c++ app has.)
On 1/19/2014 10:40 PM, Bruce Leban wrote:
I think the odds of Python getting
from __future__ import pony
are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:
from __future__ import everything
since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:
range = xrange
It's unfortunate we didn't add this (and all other changed builtins) to future_builtins in 2.7. Eric.
you’ll have to do quite a bit: # -*- coding: utf-8 -*-from __future__ import print_function, division, unicode_literals, absolute_import from io import open range = xrange str = unicode basestring = (str, bytes) #for isinstance() 2014/1/21 Eric V. Smith <eric@trueblade.com>
On 1/19/2014 10:40 PM, Bruce Leban wrote:
I think the odds of Python getting
from __future__ import pony
are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:
from __future__ import everything
since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:
range = xrange
It's unfortunate we didn't add this (and all other changed builtins) to future_builtins in 2.7.
Eric.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Jan 21, 2014, at 0:20, "Philipp A." <flying-sheep@web.de> wrote:
you’ll have to do quite a bit:
# -*- coding: utf-8 -*- from __future__ import print_function, division, unicode_literals, absolute_import
from io import open
range = xrange str = unicode basestring = (str, bytes) #for isinstance() Plus importing imap and ifilter as map and filter, and renaming modules in some way rather than just builtins, and of course you have to wrap half of that in a try and/or if sys.version_info check, or it won't run in 3.x, which defeats the purpose...
Which is why I create a project-specific module so I can just "from sixify import *" (along with the future statement, of course) at the top of every module, and it's all taken care of in two lines.
2014/1/21 Eric V. Smith <eric@trueblade.com>
On 1/19/2014 10:40 PM, Bruce Leban wrote:
I think the odds of Python getting
from __future__ import pony
are slightly higher than there being a Python 2.8. I assume by "pony" you really mean what I'd like to have:
from __future__ import everything
since my goal is to write Python 3 compatible code even though I'm temporarily stuck with Python 2 due to stack issues. The __future__ imports makes it easier to write forward compatible code. As it is, I have to list the individual imports in every file and I also add:
range = xrange
It's unfortunate we didn't add this (and all other changed builtins) to future_builtins in 2.7.
Eric.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Ethan Furman <ethan@stoneleaf.us> writes:
On 01/19/2014 03:35 PM, Ben Finney wrote:
In other words, those who want Python 2 to continue need to either bite the bullet and move their migration to Python 3 forward
Um, if they want Python 2 to continue, why would they migrate to Python 3?
One of the often-stated justifications for wanting Python 2 to continue is that the party wants to migrate their code base to Python 3, but “eventually”. With that clause, I'm pointing out that “we can't find anyone to continue maintaining Python 2 the way we want for the price we want to pay for the length of time we want to keep using Python 2” still leaves the plaintiff with the option to hurry up and migrate to Python 3. -- \ “Airports are ugly. Some are very ugly. Some attain a degree of | `\ ugliness that can only be the result of a special effort.” | _o__) —Douglas Adams, _The Long Dark Tea-Time of the Soul_, 1988 | Ben Finney
On Mon, Jan 20, 2014 at 9:33 AM, Matěj Cepl <mcepl@redhat.com> wrote:
On 2014-01-19, 03:58 GMT, you wrote:
But that doesn't stop other parties – Red Hat, ActiveState, etc. – doing so for whatever customers are still interested in compensating them for their work.
Please, this is a list with lots of recipients. Don't say "you" wrote here - use a name :) Thanks! ChrisA
On 19 January 2014 11:13, Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2014-01-18, Terry Reedy wrote:
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
Red Hat will offer commercial Python 2 support until at least 2023 (since the RHEL7 beta was just released with Python 2.7 as the system Python and the current lifecycle for RHEL releases is 10 years), and I expect other commercial redistributors will similarly extend the lifetime of Python 2 well beyond 2015 when the level of support we provide for free reverts to security fix only mode. With CentOS and other downstream community rebuilds of RHEL available, this even includes the availability of *free* prebuilt versions. So Python 2 application developers don't have anything to worry about *if they're happy with Python 2.7 as it stands*, especially after accounting for the Python 3 standard library modules that are also available on PyPI for Python 2 (or are relatively easy to fork and port back to Python 2, or just copy and paste the relevant code into a private utility module). However, now that we're approaching the release of Python 3.4 (the second Python 3 release without a corresponding Python 2 release), some Python 2 developers are finally beginning to realise how much they had come to rely on the relatively steady cadence of new features and functionality previously delivered in an easily consumable bundle by the CPython core development team. So, those developers are now faced with a few different options: - invest in migrating to Python 3 themselves (the cost of which will vary from being similar to any major Python version update, with most of the cost being in compatibility testing, to substantially more expensive, depending on the exact nature of the application, its dependencies and the quality of their respective test suites) - try to guilt the existing core developers into creating Python 2.8 for them for free (not going to happen, read PEP 404) - try to hire enough of the core developers to convince Guido to approve a Python 2.8 release from python.org (not impossible, but likely prohibitively expensive, since most, perhaps all, of the core development team are already gainfully employed elsewhere) - fork CPython to create their own Python 2.8 (also cost prohibitive from a time and materials perspective, unless you already have the infrastructure and community in place to maintain a CPython fork) That last point is relevant to the discussions around Stackless 2.8: CCP and the rest of the Stackless community have been maintaining a CPython fork for so long that the idea of porting some of the backwards compatible Python 3.3 and 3.4 changes over to a Stackless 2.8 release is a relatively straightforward one for them and something they're seriously considering. However, significant compatibility testing costs would still be incurred in a switch from CPython 2.7 to Stackless 2.8, so conservative developers are still likely to stick with the devil they know (most of the really interesting changes in Python 3 are the backwards incompatible ones, so they won't be backported, even in Stackless 2.8). There's lots and lots of info about the state of the Python 3 transition here: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_an... I'd call reading that Q&A the starting point for any discussion of creating a Python 2.8 release, but it really isn't. The starting point is a deep understanding behind the business drivers of open source based commercial operations and how they deal with cases where they depend on things that upstream has decided not to support any more. Sometimes they invest in the infrastructure needed to create their own fork (since their motivations no longer align with the existing development team's motivations), sometimes they pay commercial redistributors to continue supporting the older version (an approach I appreciate, since it represents one of the things that ultimately gets me paid), sometimes they approach the existing development team (or a related foundation) about directly funding continued development of the version being discontinued and sometimes they decide to invest in updating to the newer platform themselves. This dynamic isn't unique to open source though, as it impacts even large proprietary platform vendors like Microsoft - Windows XP almost certainly remained supported for so long because a whole lot of paying users that weren't happy with the state of Windows Vista and offered Microsoft enough money to ensure they could keep using Windows XP until Windows 7 was available. The only difference there is that in the proprietary case, the *only* option users have is to beg the vendor to continue maintenance - the options of forking or paying someone else to take up maintenance aren't available due to the licensing restrictions on the proprietary platform. Returning to the Python 3 case, as things currently stand, the combination of Armin Ronacher's python-modernize with Benjamin Petersen's six module is one approach to smooth migration, as is Ed Schofield's python-future module and its futurize tool. For application porting (which may be able to just drop Python 2 support rather than needing to maintain Python 2 and Python 3 support in parallel), Guido's original 2to3 conversion tool may suffice. PEP 461 will likely add a binary interpolation feature *back* to Python 3.5, removing an additional blocker to forward migrations for current Python 2 users (just as PEP 414 did by restoring Unicode literal support). While the Stackless community are looking at creating a Stackless 2.8 release, and some Python 2 users may decide it is worth migrating to the Stackless fork to gain access to any Python 3 features they decide to backport, rather than migrating to Python 3 itself, this is all perfectly fine - it's the open source model working *exactly as it is supposed to*, by giving people the option to take steps that meet *their* needs, rather than being completely subject to the desires of the core development team. The only thing people *don't* get to do is make suggestions about what *should* happen without also explaining: * what problem the suggestion is designed to solve, and how it actually helps to solve it * how the proposal is going to be resourced, especially when it is something the existing development team have disclaimed any interest in doing for free Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 19/01/2014 01:13, Neil Schemenauer wrote:
I don't give a shit what it's called. A Python 2 fork is going to happen whether the PSF blesses it or not, I can't believe that's even a point of discussion. People are still maintaining Cobol compilers.
I don't care what it's called either. And I'll believe the fork when I see it. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 1/18/2014 8:13 PM, Neil Schemenauer wrote:
On 2014-01-18, Terry Reedy wrote:
I realize that if there is actual code created, and if it's not under the umbrella of the PSF, it couldn't be called "Python 2.8" due to trademark reasons.
Except I did not. This is part of a quote from Martjin Faasen. You should have left the attribution and quote marks in.
I don't give a shit what it's called. A Python 2 fork is going to happen whether the PSF blesses it or not,
The core developers said years ago that if *other* people want to make a post 2.7 Python, just not called 'Python 2.8' (because we do care), they are free to. We *expect* that there will be commercial support (Red Hat, for instance) at least for keeping 2.7 updated to work on new platforms, perhaps with a few other patches. If you are correct about the tremendous demand for a 'something 2.8', then some group should be able to make money creating and selling it. However, as far as I know, no person and no corporation has yet offered money to PSF or individual core developers to develop a possibly PSF-blessed Python 2.8.
I can't believe that's even a point of discussion.
You are the one who brought it up on *this* list, where is it mostly off-topic, because *this* list is about future Python 3 versions. That was the point of me directing you to Faasen's 'something 2.8' discussion. -- Terry Jan Reedy
Neil Schemenauer writes:
On 2014-01-18, Terry Reedy wrote:
On 1/17/2014 10:22 PM, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
For application code, why does it need to be ported.
Unless Python 2.x is going to be maintained in perpetuity then code will have to be ported. This point seems obvious to me.
But it's not even true. Python 2.7 is a Turing-complete language, it can do anything that any language can do as an abstract computation, and 2.7.6 has extremely few bugs and sufficient bindings to OS facilities to do almost anything in practice as well. It's a pretty darn good language. Most Python 2 programs will probably be abandoned before Python 2.7.6 will need additional maintenance beyond what is already provided by various OS distros.
I disagree. The amount of Python 2 code that exists exceeds the amount of Python 3 by orders of magnitude. That existing codebase either stops evolving and stays Python 2 forever
But "stays Python 2 forever" != "stops evolving". There is absolutely nothing to stop a Python 2 program from evolving dramatically over the indefinite future, any more than sticking to C89 stops a lot of C programs from evolving. I don't see any real reason to suppose that most applications will find a true need to evolve in directions that Python 2 doesn't support for quite a while.
A Python 2 fork is going to happen whether the PSF blesses it or not, I can't believe that's even a point of discussion.
It's not a point of discussion. In the same sense that COBOL compilers continue to be maintained today, Python 2 was forked long ago. Not only are there non-CPython implementations of the language, every distro (commercial or not) has their own patches (perhaps a null set for Python 2.7.6). That's not going to stop, and as Nick points out Stackless is even likely to add some Python 3 features to their implementation of 2.x. But that's a specialty interest, and not even all Stackless users will necessarily use those features. I doubt many commercial packagers of CPython will have customers interested in them -- the Stackless guys want the Python 3 features for internal use as much as for their clients IIRC. But a fork of the kind you propose isn't going to happen. Definitely not under the auspices of the PSF, that's been settled with PEP 404. Nor with volunteer labor -- there aren't any volunteers for that. If there were, they would have started long ago. And I don't see a story for a commercial fork, either. The problem is that there's no "halfway point" here. Porting a program from Python 2 to Python 3 either does not require a fundamental rethink of its internal text processing, or it does. In the former case, 2to3 does a pretty good job, and what's left is a SMOP, mostly to fit appropriate decoding/encoding on to I/O. In the latter case, you've got big problems -- a complete redesign and an audit of all code for conformance to the new design. This is the watershed; there's no way to create a language intermediate between Python 2 and Python 3 so that porting Python 2 to Python-sqrt(6) is half the work, and porting Python-sqrt(6) to Python 3 is half the work.
From: Neil Schemenauer <nas-python@arctrix.com> Sent: Friday, January 17, 2014 7:22 PM
Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes.
What exactly do you mean by "the bytes/unicode changes"? There's a wide range of differences between 2.7 and 3.4 that could fall into this category. At least two of them, you'll specifically included in your proposed 2.8, including one of the three huge ones. Here's the ones I can think of off the top of my head, in rough order of most to least code-breaking: * No automatic conversions from bytes to unicode. * No automatic conversions from unicode to bytes. * Rename unicode to str (included in your suggestion). * File objects can be either unicode-based (text) or bytes-based (binary), defaulting to unicode. * The stdin/out/err files, StringIO, and various other common file objects are text. * __str__ (and __repr__) must return unicode, not bytes—and it's what print, "%s", default "{}", etc. call. * __bytes__ (the 3.x equivalent of 2.x's __str__) exists, but is not called by anything but bytes(), and is not supplied by most builtin/stdlib types (which is why, e.g., bytes(2) returns b'\0\0', not b'2'). * Dozens of builtins and stdlib functions that used to work on bytes (or, in some cases, on either bytes or unicode) now work on unicode (e.g, csv.reader, json.loads). * Default string literal as unicode (included in your suggestion; already available with a future statement). * No bytes.encode or unicode.decode. (In 2.x, when used with codecs like 'ascii' or 'utf-8' these were almost always errors… but errors that a lot of badly-written code relies on to "work", as long as you never give it a non-ASCII character.) * No bytes.__mod__ or bytes.format (at least in 3.4; this may change later). * Bytes is an iterable of small ints rather than of single-char bytes. * File objects are the wrappers from the io module, not thin wrappers around C stdio. * All text files have universal newlines enabled, unless otherwise specified by the (not in 2.x) newline param. * Functions like chr and ord are based on Unicode code points, not bytes. (There are no bytes equivalent because there's no need if bytes is an iterable of ints.) * Different internal representation for unicode objects. * Different C API for unicode objects. * No basestring. So… which of these do you want, and which do you not? I suspect that, whatever your exact answers, it would be a lot easier to fork 3.4 and port the 2.7 behavior you want than to fork 2.7 and backport almost all of 3.4. And if you do it that way, you could even adapt the idea someone proposed a few weeks ago—not popular on this list, but maybe popular with your target audience—of turning each change on and off with a "from __past__ import misfeature" statement, so people could pick and choose the ones they need, and gradually remove past statements as they port from your forked 2.8 to real 3.4. However, I also suspect that, whatever your exact answers, it won't be that useful. Look at people's reasons for not moving to 3.x: * If your app already works in 2.7, and has no need for any new 3.x-only packages, it makes perfect sense to stay with 2.7. Which means there's no reason to move to 2.8. * If your app works in 2.7, but you're worried that it will eventually become hard to find supported 2.7 installations to run on, would you really expect finding 2.8 installations to be be easier? * If you're staying with 2.7 because your OS, hosting company, dev team, school, whatever provides it, there's no reason to go to 2.8. * If you depend on a package that hasn't been ported to 3.x… well, that's four separate issues. * If you depend on an in-house/small-market package that hasn't been ported, it's really the same case as "I have an app that works just fine in 2.7." * If you depend on a package that hasn't been ported because it's effectively moribund, it's not going to be ported to 2.8. * If you depend on a package that actually has been ported to 3.x, but you're too stupid to find information anywhere but blog posts or StackOverflow questions dated 2009 (which is depressingly common…), those posts are not going to tell you about 2.8. * If you depend on a package that's legitimately hard to port to 3.x, it obviously won't be ported to 2.8 yet either—and since it'll probably be a lower priority for the developers, even if 2.8 is an easier port than 3.4 there's no guarantee it'll come sooner. (Also, consider that typically, people depend on 6 packages that have been ported and 1 that hasn't; if they switch to 2.8, that'll be 7 packages they need to wait on rather than 1.) * If you have code that sort of works in 2.7 if you're careful to feed it only ASCII, just renaming str will almost certainly break your code. If you fix it, it will be as easy to port to 3.4 as to 2.8. If you don't fix it… well, at best this is the same as the first case; if not, it's the same as the next one. * If you have code that's legitimately difficult to port to 3.x because, e.g., it relies on parsing and creating network messages or file formats that mix ASCII text and binary or encoded-text payloads, just renaming str will break your code. And it may be non-trivial to fix. I'm having a hard time imagining code that would be easy to port to 2.8, but not to 3.x. For example: payload = <some object with a __str__ method to serialize it> sock.sendall('Header: {}\r\nAnother: {}\r\n\r\n{}'.format( headers['header'], headers['another'], payload)) Even with just the two changes you already suggested: First, you have to change the literal to a bytes literal. More seriously, you have to rename that payload type's __str__ method to __bytes__. And if it does any string stuff internally, like encoding JSON, that has to change. Meanwhile, your logging code probably relies on the same _str__ method actually returning a str, so you have to add one of those. Assuming headers is a dict of strs, you either need to go back up the chain (or into the API that provides it) and change that so it's been a dict of bytes all along, or you need to explicitly encode the headers here. That doesn't sound too hard overall… but that gives you working Python 3.5 code (assuming PEP 460 goes through). And there doesn't seem to be any shortcut that would give you working 2.8 code without also working in 3.5. Also, one quick comment:
- removal of 'apply', 'buffer', 'callable',
'callable' exists in Python 3.2+. Not a big deal, unless this implies that you're basing everything on the state of the ecosystem back in Python 3.1. I don't think that it does, but just in case: Three years ago, people didn't have much experience with porting yet (e.g., writing 2.x code and running it through 2to3 at install time was considered the best way to port things gradually…) and most of PyPI didn't exist for 3.x yet. Back then, this suggestion would have been a lot more compelling than it is today, because all anyone could say was, "Wait and see, we're hoping it'll be better" instead of "Look and see, it already is better."
On 2014-01-17, Andrew Barnert wrote:
What exactly do you mean by "the bytes/unicode changes"?
I mean all of those things that you listed. bytes = the Python 2.7 str object, str object is Python 2.7 unicode object.
I suspect that, whatever your exact answers, it would be a lot easier to fork 3.4 and port the 2.7 behavior you want than to fork 2.7 and backport almost all of 3.4.
It's a lot of work no matter which way you do it. That's one of the biggest problems with this idea.
And if you do it that way, you could even adapt the idea someone proposed a few weeks ago—not popular on this list, but maybe popular with your target audience—of turning each change on and off with a "from __past__ import misfeature" statement, so people could pick and choose the ones they need, and gradually remove past statements as they port from your forked 2.8 to real 3.4.
You can't make those changes with __future__/__past__ imports. They effect the whole runtime, not single module.
However, I also suspect that, whatever your exact answers, it won't be that useful. Look at people's reasons for not moving to 3.x:
Imagine I'm a developer with the Python 2.x codebase. I'm either lazy or I'm too busy with other company projects that I can't put the effort into porting my 2.x code to 3.x, even if all the 3rd party libraries have been ported. How can we make it easier for them to move their code towards Python 3.x rather than keeping it as 2.x? A maintained interpreter to run Python 2.x code is going to continue to exist. Some python-dev people seem to suggest we can suggest that end of maintenance of Python 2.7 is going to force people to port their code. That's ridiculous. I want to make it more attractive for these developers to move towards Python 3 rather than stalling out on Python 2.7 forever. How best to do that is still to be determined. I think my 2.8 idea might be better than the status quo but it's just a crazy idea.
I'm having a hard time imagining code that would be easy to port to 2.8, but not to 3.x. For example:
payload = <some object with a __str__ method to serialize it> sock.sendall('Header: {}\r\nAnother: {}\r\n\r\n{}'.format( headers['header'], headers['another'], payload))
Even with just the two changes you already suggested: First, you have to change the literal to a bytes literal.
That part is easy, could even be done with an automated tool (change u' to ' and ' to b').
More seriously, you have to rename that payload type's __str__ method to __bytes__.
Nope, no __bytes__ in my proposed 2.8.
And if it does any string stuff internally, like encoding JSON, that has to change. Meanwhile, your logging code probably relies on the same _str__ method actually returning a str, so you have to add one of those. Assuming headers is a dict of strs, you either need to go back up the chain (or into the API that provides it) and change that so it's been a dict of bytes all along, or you need to explicitly encode the headers here. That doesn't sound too hard overall… but that gives you working Python 3.5 code (assuming PEP 460 goes through). And there doesn't seem to be any shortcut that would give you working 2.8 code without also working in 3.5.
I think you are misunderstanding my proposal, no problems like the ones you suggest, bytes() would be the Python 2.7 str class. All the internal bytes/unicode internals would be like 2.7. That's basically the whole idea of this proposal, the bytes/str change in 3.x is the really disruptive one, separate it into separate interpreter versions to make porting easier. Neil
On Sun, Jan 19, 2014 at 12:14 PM, Neil Schemenauer <nas-python@arctrix.com> wrote:
That's basically the whole idea of this proposal, the bytes/str change in 3.x is the really disruptive one, separate it into separate interpreter versions to make porting easier.
It may be disruptive to a whole lot of code that's been happily oblivious to the whole issue, but it's also central to more and more of Py3's library. It's going to become increasingly difficult to backport stuff from Py3 to a system that doesn't have the same back-end string handling. If you're prepared to make a whole bunch of incompatible changes to move to this hypothetical 2.8, why not make all the changes at once? Unless 2.x will be maintained forever (with a 2.9, a 2.10, and so on), the changes will have to be made. If it's so costly to make a full pass over your code to port it to 3.3/3.4/3.5, surely it would be twice as costly to make that exact same full pass to port it to 2.8, and then another just the same to port 2.8 to 3.6? I still maintain that the biggest complaints about the jump from 2.x to 3.x are largely dealt with by 2.7 and 3.3/3.4. Yes, it's hard to jump from 2.5 to 3.1, but you don't have to. Just stick with 2.x until your users are all on 2.7, then strip out all the code that's supporting pre-2.7 versions. Once you have that, you can start in with some __future__ directives (division, print_function, unicode_literals), and start sorting out the bytes/unicode distinction *at your leisure*. (In some cases, that "sorting out" is simply a matter of naming. I have some code that reads from a socket, and it's divided into three parts: first pass works with "data" and handles TELNET codes, second pass works with "text" and handles ANSI codes, third pass works with "text" and handles newlines. It's obvious from the parameter names that the conversion from bytes to Unicode has to happen between the first and second passes.) Then, when you finally come to port it to 3.x (which mightn't be for another however-many years, when 2.7's python.org support finally ends, or it might be even later, when RHEL stops shipping patches, or it might not even be then - code doesn't stop working just because it's not supported), you make the jump to whichever version is most convenient. Currently, I'm seeing 3.3 as easier to jump to than 3.2 (eg the redundant compatibility notation u"str" is available), and 3.4 is getting some more on that front; maybe some features won't make it into 3.4 so they'll be in 3.5. And maybe it'll be 3.7 that you jump to. That's not a problem. Whatever version you port it to, you make *one* assault on your code, and there you are, taking advantage of exactly as much of 3.x as you feel like, and it's all working. ChrisA
On Sat, Jan 18, 2014 at 07:14:13PM -0600, Neil Schemenauer wrote:
On 2014-01-17, Andrew Barnert wrote:
And if you do it that way, you could even adapt the idea someone proposed a few weeks ago—not popular on this list, but maybe popular with your target audience—of turning each change on and off with a "from __past__ import misfeature" statement, so people could pick and choose the ones they need, and gradually remove past statements as they port from your forked 2.8 to real 3.4.
You can't make those changes with __future__/__past__ imports. They effect the whole runtime, not single module.
I believe you are wrong. from __future__ imports are designed to effect the single module they are in. I see no reason why from __past__ can't work the same way. [steve@ando ~]$ cat a.py def func(): return "Hello World" [steve@ando ~]$ cat b.py from __future__ import unicode_literals def func(): return "Hello World" [steve@ando ~]$ python2.7 -c "import b, a; print repr(b.func()), repr(a.func())" u'Hello World' 'Hello World' -- Steven
On Fri, Jan 17, 2014 at 09:22:19PM -0600, Neil Schemenauer wrote: [...]
Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes. This could include:
It's hardly a "far out" idea. You're not the first to suggest this. There are many people asking for -- demanding, almost -- a Python 2.8 that provides only the subset of Python3 that they are interested in and gives them an excuse to avoid migrating for another three or five or ten years. Because really that's what 2.8 is all about -- providing people an excuse to put off migrating for a bit longer. But the thing is, they've still got a good three or more years before 2.7 goes into "security patches only" mode, and likely years more before it becomes unmaintained. And then there's third-party support from companies like RedHat. They will continue supporting Python 2 until end of 2023: https://access.redhat.com/site/support/policy/updates/errata/#Life_Cycle_Dat... I wonder whether the 2 to 3 transition might not have been handled better with a long-drawn out process of slowly adding backwards-incompatible changes a few at a time? This is like the old chestnut about whether it is better to ease yourself into a really cold swimming pool a little at a time, or get it over with in one go by diving in. In both cases, you have pain, is it better to have a lot of pain that only lasts a short while, or a little bit of pain that goes on and on and on and on...? I think that had Python decided to add backwards-incompatible changes a few at a time, people now would be complaining about that and demanding that there be a once-off cutover version.
- removal of 'apply', 'buffer', 'callable', 'execfile'
callable is back in Python 3.3.
Problems with this idea:
- it would be a huge amount of work. [...]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
An alternative approach to producing Python 2.8 would be to start with the Python 3.x latest branch. Modify bytesobject and unicodeobject to have as close to Python 2 behavior as practical.
A-journey-of-a-thousand-miles-begins-ly y'rs
The journey *already began* back in Python 2.6. Python 2.6 is the start of the journey, it introduces dict views, next() builtin, from __future__ absolute_import print_function and unicode_literals, and probably more that I have forgotten. So really, people have had 2.6 and 2.7 to ease the transition from 2.5 to 3.x. If they haven't taken advantage of that, what makes you think that 2.8 and 2.9 will convince them to migrate? But you don't have to believe me. Python is open source. Feel free to fork it and backport whatever features you like, and see how much interest you get from the wider community. Just don't call it "2.8", that sends the wrong message and is a pretty rude thing to do given that the core developers have said that they will not make a 2.8: http://www.python.org/dev/peps/pep-0404/ Just because there will not be a CPython 2.8 doesn't mean you can't go ahead with your plan to backport 3 features to a 2 base. Just call it something else. -- Steven
Steven D'Aprano, 19.01.2014 03:28:
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
Thank you, Steven, for taking the time to write this post. Stefan
On 2014-01-19, Steven D'Aprano wrote:
[Neil]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
That would be progress though. My proposed 2.8 would have most of the incompatible changes from 3.x so if people port it they will be much closer to 3.x. Neil
On Mon, Jan 20, 2014 at 1:18 AM, Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2014-01-19, Steven D'Aprano wrote:
[Neil]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
That would be progress though. My proposed 2.8 would have most of the incompatible changes from 3.x so if people port it they will be much closer to 3.x.
I still haven't seen any evidence that porting half-way and then half-way again later is going to be less work than just biting the bullet and porting to 3.x (either sooner or later, whichever is more convenient). ChrisA
On Sun, Jan 19, 2014 at 2:22 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Mon, Jan 20, 2014 at 1:18 AM, Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2014-01-19, Steven D'Aprano wrote:
[Neil]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
That would be progress though. My proposed 2.8 would have most of the incompatible changes from 3.x so if people port it they will be much closer to 3.x.
I still haven't seen any evidence that porting half-way and then half-way again later is going to be less work than just biting the bullet and porting to 3.x (either sooner or later, whichever is more convenient).
All of these threads do remind me of the Achilles Paradox.
On Sun, 19 Jan 2014 08:18:19 -0600 Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2014-01-19, Steven D'Aprano wrote:
[Neil]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
That would be progress though. My proposed 2.8 would have most of the incompatible changes from 3.x so if people port it they will be much closer to 3.x.
Not sure how code that would be incompatible with both 2.7 and 3.x should be considered progress. Regards Antoine.
On Sun, Jan 19, 2014 at 08:18:19AM -0600, Neil Schemenauer wrote:
On 2014-01-19, Steven D'Aprano wrote:
[Neil]
- if people install this new version of Python as the default, old scripts and programs will break. [...]
- It gives people an excuse to avoid migrating, and as sure as the sun rises in the east, will lead to people calling for Python 2.9 a few years from now.
That would be progress though. My proposed 2.8 would have most of the incompatible changes from 3.x so if people port it they will be much closer to 3.x.
Progress towards what, though? You say that they will be "closer" to migrating, but another way to look at it is that they will be *further away* from migrating: - the only work they have to do is the easy parts, like adapting from zip returning a list to zip returning an iterator, in other words the part of the migration which can be handled by a simple-minded mechanical script like 2to3; - in return they get access to many of the desirable new features of Python 3; - which reduces their incentive to tackle the big, difficult, structural changes needed for Python 3 (e.g. handling text as Unicode properly). To me, that's a step backwards. One aim here is for the core developers to have one code base to maintain, not two. My grateful thanks to them for taking on all this extra work, and it has been a lot of work, to make it easier for users to migrate, but enough is enough. Adding 2.8 will extend that burden on the core developers by at least three years (18 months of active development plus 18 months of security features); adding 2.9 by the same again. It is entirely appropriate for the core devs to draw a line and say *this is when we stop supporting Python 2*, and that line has been drawn a long time ago at 2.7. If people don't migrate after a decade, they won't migrate after 16 years, especially if they get "all the good bits" apart from the Unicode text model (which many English speakers don't care about), so what you're actually suggesting is that the core devs agree to an extra 3-5 years of maintaining the 2.x series for the sake of people who will very likely never migrate to 3.x. -- Steven
Steven D'Aprano writes:
To me, that's a step backwards.
I agree, but this kind of "step backwards" is a "consenting adults" issue. So let's avoid such pejorative terminology, and stick to the line that a lot of resources would be required to create such a Python 2.8, and there's little benefit to be had.
On Mon, Jan 20, 2014 at 2:06 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Steven D'Aprano writes:
To me, that's a step backwards.
I agree, but this kind of "step backwards" is a "consenting adults" issue. So let's avoid such pejorative terminology, and stick to the line that a lot of resources would be required to create such a Python 2.8, and there's little benefit to be had.
No, I'm with Steven on this. (Steven with a v, as opposed to Stephen with a ph. It's like talking to the detectives in Tintin.) Even if it cost no resources at all - if Python 2.8 already existed, exactly as described - it would be a third Python to aim for (as well as 2.7 and 3.x). It's already hard enough to span lots of Python versions; adding another that's deliberately and consciously incompatible with both the primary branches would be a major problem. It may be that code that runs on 2.7 and 3.4 will also automatically run on 2.8 (which seems possible, but far from certain), but if not, 2.8 would cause problems for everyone who tries to write code for every supported version. For anything other than in-house scripts where one person/team controls both the script and the interpreter it runs on, compatibility with multiple versions will be critical; and adding something incompatible with both current versions is an XKCD 927 situation [1]. No matter how cheap or expensive it is to do, that's a problem *in itself*, so the proposal has to justify itself enough to overcome that. ChrisA [1] http://xkcd.com/927/
On Sat, Jan 18, 2014 at 6:22 AM, Neil Schemenauer <nas-python@arctrix.com> wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported.
That's a common illusion. Python 2 is a good binary language, Python 3 is a good text language. Leaving things as-is saves lifetime and energy. There is a conflicting constraint that you can't get all three: 1. readable language 2. work with strings as abstract unicode datapoints 3. work with strings as binary data Python 2 was more explicit for unicode data (and this was tiresome for text lovers) and Python 3 is explicit about binary (which makes life harder for those who work with binary data).
One of the most disruptive changes in Python 3 is the strict separation of bytes from unicode strings. Most of the other incompatible changes can be handled by 2to3.
2to3 is far from being a perfect tool, not a user level one, for sure, but I don't maintain list of all things that cause troubles. Probably the major one is that there is no docs how to write own fixers (and you need that for 3rd party projects). The thing I disagree is that incompatible changes can be handled by 2to3. There are many internal things that make Python 3 awesome, but they were not ported to Python 2, because people wanted "the next better thing" and thought about Python 2 as a dead end. Some of us still think this way, but I hope that recent threads made them more flexible. Many internal features would be good to be backported into Python 2 series and these are invisible on 2to3 level.
Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes. This could include:
- print as function
- default string literal as unicode
And this will be literally the end of Python 2.8 in the same way as Python 3. Just attach here the list of consequences. Good exercise for story-writing: "And now all strings are unicorne".
- return view objects for dict.keys(), etc
- rename modules in standard library
- rename long to int
- rename .next() to __next__()
- accept only new 'raise' syntax
- remove backticks for repr
- rename unicode to str
- removal of 'apply', 'buffer', 'callable', 'execfile'
- exec as function
- rename os.getcwdu() to os.getcwd()
- remove dict.has_key
- move intern to sys.intern()
- rename xrange to range
- remove xreadlines
New features of Python 3.x could be backported if easy since they could be useful to entice developers to move from 2.7 to 2.8.
What if people don't need bloated Python with all there features? What if Python 4 should not only move stdlib into modules, but features also? I look at this list as an RPG called "Personal Python". You generate you character by selecting traits you like. Some of them are conflicting like "default binary vs unicode". Once your character is ready, you may start to play with it. Probably something I'd expect from PyPy project, but well it requires more engineering and experiment time than it is possible in open source projects. Here is the idea without implementation how to pack those features: http://techtonik.rainforce.org/2013/04/program-config-as-dna-strand.html
An alternative approach to producing Python 2.8 would be to start with the Python 3.x latest branch. Modify bytesobject and unicodeobject to have as close to Python 2 behavior as practical.
I'd start with PyPy. They need more help with Python 3 transition.
A-journey-of-a-thousand-miles-begins-ly y'rs
On Saturday, January 18, 2014 2:22:19 PM UTC+11, Neil Schemenauer wrote:
The transition to Python 3 is happening but there is still a massive amount of code that needs to be ported. One of the most disruptive changes in Python 3 is the strict separation of bytes from unicode strings. Most of the other incompatible changes can be handled by 2to3.
Here is a far out idea to make transition smoother. Release version 2.8 of Python with nearly all Python 3.x incompatible changes except for the bytes/unicode changes. .....
I now feel the python 3 - python 2 bridge idea is a far better solution. The problem is real, but this is not the solution
participants (20)
-
anatoly techtonik -
Andrew Barnert -
Antoine Pitrou -
Ben Finney -
Bruce Leban -
Chris Angelico -
Eric V. Smith -
Ethan Furman -
ian o -
Mark Lawrence -
Matěj Cepl -
MRAB -
Neil Schemenauer -
Nicholas Cole -
Nick Coghlan -
Philipp A. -
Stefan Behnel -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy