[talentedcoin]

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?

[RussianCow]

> 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.

[solarkraft]

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)?

[RussianCow]

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. :)

[takeda]

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)

[shadowgovt]

> 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.

[readmodifywrite]

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.