[Python-Dev] The end of 2.7

Guido van Rossum guido at python.org
Sun Apr 7 20:02:05 CEST 2013


I have spent many years  in industry working for large companies that
have big, successful internal Python code bases, with dependencies on
large numbers of external packages. From talking about colleagues
about migrating to new language versions, several issues come forward.
They all conspire to make it hard to move forward, but not impossible.

- A single external package that doesn't yet support the new version
can block migration until it has been ported or been replaced by
something else.

- Many third party packages change their API as they move forward
(sometimes they are forced by changes in the language). This means
trouble in the backwards compatibility department.

- A migration takes a lot of effort. You have to put several engineers
on it full-time who could otherwise be developing new features; and it
disturbs the development activities of many other engineers, who will
be asked to fix tests, decide whether something is still used, and so
on.

- There are probably parts of the codebase that depend extensively on
some feature that doesn't work in the new version, e.g. str/unicode
equivalency. Yes, that code is probably buggy, but it is heavily used,
and rewriting it means changing interfaces between different
components, which in turn requires more rewrites.

- There are probably different departments within the company that
move at different speeds. It is extremely difficult to get everyone to
switch at the same time. So you have to come up with some kind of
gradual transition plan, which will probably make the effort even more
work, by requiring backwards compatibility for some internal
interfaces.

- Even if everything goes extremely smoothly, you can still count on
some interruption of production -- outages, performance degradations,
all the things that end users notice and gripe about. The prospect of
this makes managers *very* uncomfortable.

But, despite all this, migrations happen all the time, and I am sure
that Python 3 will prevail as time progresses. For many *users*,
Python 3 may be a distraction. But for most *developers*, maintaining
2.7 is a distraction. By and large, users of 2.7 don't need new
features, they just need it to keep working. And it does, of course.
(At the risk of a flawed analogy: Windows XP is still the best version
of Windows for hardware built when XP was current.)

But perhaps we could change the focus for 2.7 development a bit:
instead of fixing bugs (or bickering about whether something is a bug
fix or a new feature) we could limit changes to ensuring that it works
on newer platforms. Martin mentioned that building 2.7 for Windows
with the same toolchain that was used for the 2.7.0 release is getting
more and more problematic. I'm not sure, but I could imagine similar
problems for future versions of OS X and even Linux (though the Linux
distributions typically take care of issues themselves).

There's not much of a point in fixing bugs that always existed in 2.7,
since must 2.7 users are by now used to working around these. However,
I do see a point in supporting builds targeting newer OS versions.
This won't be much of a relief for Martin, but it might be one of the
best ways to interpret "support" of Python 2.7 for the next several
years. I would also support having a 3rd party doing this and sell the
binaries for a small fee (ActiveState started out this way) -- but it
would still behoove us to have the necessary build files in the core
repo.

Some final words: if any of the alternate Python implementations
(IronPython, Jython, PyPy, even Cython) are feeling down on Python 3
because they do not have enough volunteers to help with the port (even
though at least for IronPython and Jython, the new str/bytes model is
much more suitable than the old), they should apply to the PSF for
funding. I believe PyPy is already in the process of doing so.

--
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list