Python 3 is killing Python

[Chris Angelico]

On Tue, Jul 15, 2014 at 11:57 PM, Kevin Walzer <kw at codebykevin.com> wrote:
> The number of language revisions that result in deliberate, code-level
> incompatibility out there is pretty small. People rightly expect that code
> written for version 2.x of a language will continue to work with version
> 3.x, even if 3.x is designed to go in another direction.

That's not strictly true. I would generally expect some concept of
version numbering along the lines of semver.org's recommendations, or
the Debian packaging guidelines (I think), or, or, or, or, or. You
know the sort of thing: major.minor.revision, where "revision" changes
shouldn't break anything unless you were, perhaps unwittingly,
depending on a bug; "minor" changes add features, and might break code
that was, say, using a new language keyword as an identifier (eg you
can use "with" as a function name in Python 2.4, but in Python 2.6
that won't work); and "major" changes can cause backward
incompatibility. That's not absolutely strictly true of all Python
versions, but it's certainly very close.

You would expect Python version 3.x to be broadly the same language as
Python 2.x, but you cannot expect code to automatically run
unmodified. That's the whole point of a major version number change.
And that's exactly what we see; the similarities between Python 2.7
and 3.4 are pretty huge compared to the differences. They are
definitely the same language.

> I can only think of two widely used languages in the last decade where there
> was this type of major break in binary compatibility: Perl and Visual Basic.

ANSI C broke quite a bit compared to previous C implementations.
Doesn't have quite a "version number", but it's the same concept.
Object REXX (OREXX) breaks several things in Classic REXX (REXX). Both
of those precede "the last decade", but I'd say the same thing
applies: if the name or major version number changes, you can expect
differences.

(For this reason, I have never actually released a RosMud version 2.0;
once I went stable with 1.0, I never needed to make
backward-incompatible changes. The latest - and probably last -
version is 1.7.0, and the project has been succeeded by Gypsum, which
is a brand new project... new name, incompatible APIs.)

> I've stayed with Python 2.7 because I've seen no benefit in 3.x that
> outweighs the hassle of going through my code line by line to make it
> compatible.

And that's fine! The python-dev team has promised that 2.7 will
continue to be supported; that means some headaches, especially on
Windows (the Python 2.7 support will long outlast upstream Microsoft
support for the compiler it's built on), but it's a promise that you
can continue to run your 2.7 code.

That said, though, I would advise you to give 2to3 a shot. You never
know, it might do exactly what you need right out-of-the-box and give
you a 3.x-compatible codebase in one hit.

> Though I expect I will eventually update to 3.x, however, like many other
> developers I am also annoyed by the decision to break backwards
> compatibility in Python. The decision strikes me as arrogant. Cruft and
> backwards compatibility are an inevitable part of any mature programming
> language, and maintaining compatibility is important--more important than
> bolting on shiny new features, in my view. If shiny new features must be
> added, they should be added side-by-side with older API's.

Big problem with that: it means that everyone who learns the language
has to wrestle with *both* APIs. It's impossible to fix bugs. So how
about this as a compromise: We'll have this special flag at the top of
the program that says whether it should be in "compatibility mode" or
"shiny new features mode". And hey, let's write it like this:

#!/usr/local/bin/python2
# This program runs in compatibility mode.

#!/usr/local/bin/python3
# This program gets all the new features.

Python *is* maintaining backward compatibility. It's fundamentally not
possible to add some of Python 3's features without some pretty big
changes (look at, for instance, the str/bytes changes - essential to
proper i18n, but impossible to do to a Py2-compatible interpreter), so
the only way to do it is to continue to support Py2 while doing new
development on Py3.

> I think the Python developers have undervalued the conservator part of their
> role.

No, they haven't. That's exactly why Python 2.7 is to be supported for
so long (2020 according to current plans), and why PEP 466 and such
are so important. There's a lot of Python 2 code out there, and
python-dev's taking the responsibility very seriously.

> ... I see Python 3.x's failure to silently and
> successfully import 2.x code as a failure on the language's end.

Fine. Tell me how you would go about adding true Unicode support to
Python 2.7, while still having it able to import an unchanged program.
Trick question - it's fundamentally impossible, because an unchanged
program will not distinguish between bytes and text, but true Unicode
support requires that they be distinguished. The best you could do
would be to rewrite your code into some kind of hybrid, which would
then be able to run on both versions; there are ways of doing this,
but if you're going to rewrite your code, you may as well go straight
to Py3 and take advantage of its features.

Ultimately, the solution is simply to keep Python 2.7 around for a
good long time, until the carrot of new Py3 features becomes
attractive enough for it to be worth switching. And if that's not
before 2020, no problem. Even if it's after 2020, there's a fair
chance that you'll still be able to run your 2.7 code - it's just that
there's no promise (at the moment) of patches, even security patches,
from python.org. If you're running RHEL, you might get full support
for several more years after 2020. That's a pretty long time, when you
consider that Python 3.1 came out in 2009.

ChrisA