> No bugs fixed

At this point, I've helped port multiple code-bases in multiple companies. Porting to Python 3 actually can and does fix some bugs, as it generally forces the code to start handling text semi-correctly, instead of just hoping the bytes go through and it all works out.

> Your downstream customers receive very little benefit for this effort,

They do, actually. Again, while I was porting those same code-bases, I'm working with a team of engineers who (and along with myself) are also still adding code to meet other incoming requirements. And in my experience, there was a fair bit of "Boy, it'd be nice if X were easier in Python!" where X is something that is easy in Python … 3. The question would have often gone unanswered had we not had devs experienced with Python 3 on the team.

Porting to 3 gets you all the additions that have come to Python that haven't been backported. A better standard library, syntax that better supports you, etc., translate to better productivity for devs as they are now equipped with better tools. This is only going to get worse as libraries drop support for 2.

(And while many things have been backported into third-party libraries, not all of them have, and in particular, syntax changes. And the existing backports are actually quite useful during the process of porting: I can change the code to conditionally depend on the backport library in 2, and use the real deal in 3.)

It sounds like you had a project that really benefited from updating, and that's great! Some of mine have as well.

It is not universally applicable, however. There's a lot of old code that, as I said before, is just fine. Adding a 100 line feature in the old version is easier than porting the whole 10,000 lines over. Just ask COBOL programmers what they're up to right now - it's not porting to a modern environment, it's maintaining the old one.

The other major issue is that Python 3 really didn't fix the major issues with Python that persist to this day. Atrocious byte code performance, a really awful deployment story, and perennial favorite: the GIL. Had just one of these been tackled in Python 3, the migration probably would've happened a lot faster. You might not care about those problems or they may not be problems for you, but they are for some of us and they persist to this day.

I will concede that on the whole, Python 3 is a better Python. But it's not 2x or 3x better. It's 10-20% better, and that's a tough sell to a busy engineer who has better things to do. I can't justify spending time on anything that is a mere 10% improvement when I have a pile of 2x improvements to work on.

I appreciate what you folks are saying, but from my perspective this is exactly what I mean by the absence of a "good technical reason".

I also appreciate that there are a small number of projects (e.g. PyPy) that probably do require some of the special sauce around CPython 2.

But for everyone else ... come on folks. We're developers and engineers, we're supposed to be the creative builders of tomorrow and all that stuff. Is this really so hard?

> Is this really so hard?

Absolutely, especially when there is no tangible benefit to doing so. At $day_job it took us over a month to convert our codebase to Python 3 (bit by bit, not all at once), and we still ended up running into errors in production. In our case, we were forced to make the switch because we needed to upgrade some libraries that had dropped Python 2 support, but there is plenty of software out there that Just Works™ and nobody wants to touch it (for good reason!). In those cases, it's way less expensive to pay someone to maintain the interpreter than it is to take on the effort of a full blown conversion.

How did you do it bit by bit? Running multiple interpreters (I'd imagine that to be another major effort - then again possibly well worth it if you're moving to a services architecture anyway)?

Kind of, but probably not in the way you're thinking. All I meant is that we transitioned each of our services from Python 2 to code that was compatible with both Python versions, one by one. We tackled one aspect of Python 3 support at a time, e.g. imports, strings, integer division, third-party libraries, etc. Between future imports and utility librariess like six, most things were fairly easy to make compatible across both versions.

Once we did as much as we could do on Python 2, we had one of our engineers maintain a separate Python 3 branch in a staging environment for a while (maybe two weeks?) that we did some heavy QA on. And once we were fairly confident in the results, we merged and released that over a weekend and fixed issues as they came up.

We did all of this once for each service, but the bulk of the work (>80%) was our legacy monolith. I think the whole thing would have taken way less time with better test coverage, but alas. :)

There's a way, but I did not do it outside of just POC. It's actually possible to compile legacy code using Cython and import it to python 3, then I suppose you could convert one file at a time.

It's possible that this might be more work that if you would use pylint, mypy, python-future. Also it probably won't work if your code tries to be clever and does some import hacking (although who knows, maybe it still would work)

> Is this really so hard?

90% of computer engineering isn't writing software. It's logistics, organization, and incentives.

For Python 3, I think it fell down hard on incentives. It was better, but not better enough to justify rewriting code that worked for a lot of teams, for a lot of years.

When you go to make incompatible changes and you find your userbase kicking and screaming against following you, that's not a technological problem, but it is a problem.

The issue here is opportunity cost. It has nothing to do with difficulty. The time spent porting to Python 3 has to provide a better return on investment than the same time spent doing something else. For a lot of people for a very long time, continuing to now 12 years later, that opportunity cost was such that porting to Python 3 was always a lower priority.

Languages need to serve their users, not the other way around. A lot of us really didn't care about minor syntax tweaks and we didn't need a lot of the new features. What we needed was better performance and a better deployment story, and we have received neither.