Blog "about python 3"

[Steven D'Aprano]

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