Last time, I talked about Python 3 from the perspective of a Unix sysadmin. Today I want to talk about Python 3 from the perspective of someone who has a not insignificant amount of current Python code. I don't have huge (by Python standards) programs, but I do have various things (not all large) currently running live, for real, doing things that I care about.

Recently I read Armin Ronacher's Thoughts on Python 3, where he wrote (among other things):

Because as it stands, Python 3 is the XHTML of the programming language world. It's incompatible to what it tries to replace but does not offer much besides being more "correct".

I'm kind of sad to say this, but what he said (down to the comparison with XHTML).

Some of my code has a decent amount of tests but not all of it, and all of it currently works. Migrating it to Python 3 requires a significant amount of effort and testing, even for the code that has tests, and in exchange I get basically nothing except a warm fuzzy feeling that I am 'modern'. It would be pure make-work. Worse, it would be make-work that runs a good risk of destabilizing working code.

There are two aspects to the problem. The first is simply that Python 3 is a big change from Python 2. I'm willing to make small or moderate changes purely for compatibility purposes, but I've certainly been left with the impression that Python 3 requires some significant changes (even if a number of them will work in Python 2.7, the issue is the amount of changes to the current code). The second is that Python 3's handling of strings and Unicode demand an architectural change in code that is currently ignoring the issue and just shoving around plain byte strings, which describes all of my current code. Part of this is just switching to Unicode by itself, but part of it is that since conversions to and from Unicode can fail I now need to find all of these places and figure out what I want to do.

(This also increases the risk of the changes. If I miss a place where a conversion can fail, my code may blow up at some point in the future with uncaught exceptions in a situation where it works today. This is not really an attractive selling point and yes, I would rather have mojibake than explosive failures. Among other reasons, to a first order approximation mojibake is caused by someone else's mistake while uncaught exceptions are clearly my fault.)

The result is that I can't possibly justify migrating any significant amount of my current code to Python 3 (either to myself or to others). It will remain Python 2 code unless and until I have no choice, and if I stop having a choice I'm going to fiercely resent it.

(This is entirely apart from any pragmatic issues such as dependencies that haven't yet been ported to Python 3. Most of my code doesn't use third-party modules or code anyways, just standard library stuff.)