Steven D'Aprano wrote: > On Mon, 30 Dec 2013 19:41:44 +0000, Mark Lawrence wrote: > >> http://alexgaynor.net/2013/dec/30/about-python-3/ may be of interest to >> some of you. [...] > I'd like to know where Alex gets the idea that the transition of Python 2 > to 3 was supposed to be a five year plan. As far as I know, it was a ten > year plan,
I haven't been able to find anything in writing from Guido or the core developers stating that the transition period was expected to be ten years, although I haven't looked very hard. I strongly recall it being discussed, so unless you want to trawl the python-dev mailing list, you'll just have to take my word on it *wink* PEP 3000 makes it clear that Guido van Rossum expected the transition period to be longer than usual: [quote] I expect that there will be parallel Python 2.x and 3.x releases for some time; the Python 2.x releases will continue for a longer time than the traditional 2.x.y bugfix releases. Typically, we stop releasing bugfix versions for 2.x once version 2.(x+1) has been released. But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. [end quote] http://www.python.org/dev/peps/pep-3000/ A five year transition period, as suggested by Alex Gaynor, simply makes no sense. Normal support for a single release is four or five years, e.g. Python 2.4 and 2.5 release schedules: * Python 2.4 alpha-1 was released on July 9 2004; the final security update was December 19 2008; * Python 2.5 alpha-1 was released on April 5 2006; the final security update was May 26 2011. (Dates may be approximate, especially the alpha dates. I'm taking them from PEP 320 and 356.) Now in fairness, Guido's comment about "well into 3.1 or 3.2" turned out to be rather naive in retrospect. 3.4 alpha has been released, and support for 2.7 is expected to continue for *at least* two more years: http://www.python.org/dev/peps/pep-0373/#maintenance-releases which means that 2.7 probably won't become unmaintained until 3.5 is out. In hindsight, this is probably a good thing. The early releases of 3.x made a few mistakes, and it's best to skip them and go straight to 3.3 or better, for example: - 3.0 was buggy enough that support for it was dropped almost immediately; - built-in function callable() is missing from 3.1; - 3.1 and 3.2 both have exception chaining, but there's no way to suppress the chained exceptions until 3.3; - 3.1 and 3.2 don't allow u'' strings for compatibility with 2.x. The 2.8 un-release schedule goes into more detail about the transition, and why there won't be an official 2.8 blessed by the core developers: http://www.python.org/dev/peps/pep-0404/ (Python is open source -- nothing is stopping people from forking the language or picking up support for 2.7. I wonder how many Python3 naysayers volunteer to support 2.x once the core devs drop it?) As of June this year, over 75% of the top fifty projects hosted on PyPI supported Python 3: http://py3ksupport.appspot.com/ and the Python Wall Of Shame turned majority green, becoming the Wall Of Superpowers, at least six months ago. (Back in June, I noted that it had changed colour some time ago.) Alex's claim that "almost no code is written for Python 3" is, well, I'll be kind and describe it as counter-factual. Alex points out that the companies he is speaking to have no plans to migrate to Python 3. Well, duh. In my experience, most companies don't even begin planning to migrate until six months *after* support has ended for the systems they rely on. (Perhaps a tiny exaggeration, but not much.) I won't speak for the Windows or Mac world, but in the Linux world, Python 3 usage depends on the main Linux distros. Yes, ArchLinux has been Python 3 for years now, but ArchLinux is bleeding edge. Fedora is likely to be the first mainstream distro to move to Python 3: https://fedoraproject.org/wiki/Changes/Python_3_as_Default Once Fedora moves, I expect Ubuntu will follow. Debian, Centos and RedHat will probably be more conservative, but they *will* follow, at their own pace. What are the alternatives? They're not going to drop Python, nor are they going to take over support of 2.x forever. (RedHat/Centos are still supporting Python 2.4 and possibly even 2.3, at least in name, but I haven't seen any security updates come through Centos for a long time.) Once the system Python is Python 3, the default, no-brainer choice for most Python coding will be Python 3. Alex says: [quote] Why aren't people using Python 3? First, I think it's because of a lack of urgency. Many years ago, before I knew how to program, the decision to have Python 3 releases live in parallel to Python 2 releases was made. In retrospect this was a mistake, it resulted in a complete lack of urgency for the community to move, and the lack of urgency has given way to lethargy. [end quote] That's only a mistake if you think that migrating to Python 3 needs to be *urgent*. But it isn't. It's actually a *good thing* if people and companies can take their sweet time migrating to Python 3. Let's jump back five years ago. Had Guido announced that Python 2.6 would be followed by Python 3.0, with little in the way of a transition, people would have been faced with three unpalatable choices: 1) dig your heels in and stay with Python 2.6 without upstream support or security updates; 2) migrate to an essentially untested, backwards-incompatible version of Python which is likely to be buggy (as indeed Python 3.0 turned out to be); 3) or migrate to some other language. None of these are good choices, but the difference between 2 and 3 would have been small: with none of the big frameworks and libraries like numpy or Zope migrated to Python 3, moving to a completely new language would have seemed like a reasonable choice. Choose between getting stuck half-way through a transition because only some of the libraries you need have been ported, versus move to a new language where you know (or at least *think* you know) the risks? Rushing the transition like Alex suggests would have killed Python. Instead, companies will move when they're ready. Yes, there will be a deadline, probably in 2017 or 2018, but in the meantime early adopters get to file back the sharp corners and Python 3.x gets many years to iron out the bugs. Back when Python 3 was just started, nobody thought that it would be plausible to have a single code base handle 2.x and 3.x. It turns out that for many projects, that's actually easier than trying to migrate code with 2to3. That's the sort of thing which early adopters discovered. Slow-coaches will find it easier later on because we've had so many years for the transition. Alex thinks that the reason people haven't migrated to 3.x is because of a lack of urgency. And his solution to this lack of urgency is to *reduce* the level of urgency by another 4 or 5 years by adding a version 2.8. And no doubt when that fails to work, he'll suggest giving them another 4 or 5 years with version 2.9. "Hurry up, we're waiting! If you don't hurry up, we'll wait longer!" I don't think Alex has thought his plan through, unless his plan is actually to kill Python 3. -- Steven -- https://mail.python.org/mailman/listinfo/python-list