Could you precis why it's taking multiple years? Surely there's a formal equivalence that could be automatically implemented wrt the code itself?
PEP 461 was the bare minimum we needed before porting to Python 3 could happen:
http://legacy.python.org/dev/peps/pep-0461/
We needed a way to put things into bytestrings.
And after that, it's just nothing but work. Lots of it. Little of which could be automated.
I get a little impatient, personally, with people who think that upgrading software is easy. We don't actually care about Python. We care about version control. Python is just some thing in the middle that is helping us produce version control. A multi-year effort to upgrade to Python 3 (or 3.8 or whatever) isn't giving us or our users a net benefit. In fact, until recently, it was a net loss, because Python 3.5 or 3.6 had slower warmup time, which is terrible for a tool like hg that needs to pay that cost every time you run any command.
Instead, Python 3 created busy work. Almost five years of it.
I assume you're not getting paid for it, so besides bragging rights or a nice CV entry, what else is there for you to look towards?
Mercurial's greater modularity also has made it easier to implement improvements for monorepos, although personally that's less important to me.
That's why I still use and work on Mercurial.
Git is not horrible to use. And even before I was a proficient Git user, mercurial was giving a team of 5 people a lot of work trying to fix stuff that just works on Git.
Yes, I know that Python 2.x and 3.x handle bytes entirely different, yet I cannot understand how Python and their release planning should blindly "bend" to the demands of a project using the language.
I understand you don't care about Python the least, but we do? We have to? I think that the maintainers simply had to move forward at some point, there has been a way too long grace period.
And Python is not ANSI C. I think what you want of Python is to be never-ever-changing C89 and gcc still supporting it (I think it still does?)
More seriously, there's also quite a bit of Rust now.
The decision to make it not backward-compatible and thereby force-deprecate millions of lines of working Python code was extremely expensive.
My previous employer did most of the ATE, quality, and production control in Python; and hardware drivers mostly in C. It worked reliably for about 15 years. During late 2017, the new 'code boss' mandated Python 3 for new stuff, and to convert as required for existing stuff.
Production continued with little or no problems until an important customer did a major spec change, plus the new safety and EMC regulations and standards became effective, so we had to get some stuff re-certified and some processes accredited (again). After three months, the boss fired the three programmers and assigned the task to the quality, manufacturing and regulatory engineers. We looked at the code for a few days, then said nope and re-designed and wrote in C/C++. When I left in November, things were humming along well, but the parent company saw this as a huge future liability and commenced to shut down that part of the company that made that class of widgets. Think about - a group of less than 40 production people and a few engineers that pumped 25 million USD profit annually into the mother company was dropped because of potential future code shenanigans.
Because of these experiences, I discourage use Python professionally (unless the contract allows for some specific indemnity clauses) for quality and manufacturing, and know of other manufacturing and hardware activities abandoning Python for new stuff and 'returning' to C and C++. I continue to enjoy and use Python (mostly 3) for personal projects, where support and making money do not always matter.
I'm inclined to believe them compared to some random stranger who asserts that it should be easy for Mercurial to be ported to Python 3.
Unless you were saying that most other/non-Mercurial programs are easy to port to Python 3, which could be true.
I understand your opinion: It is the party line. But it doesn't actually help much when the process as described will take years and people only have months, and this is further worsened by the fact that PSF did not have to deprecate the entire Python 2 ecosystem in order to stop supporting CPython 2.7.
The writing was on the wall ten years ago. Failure to take action is not Python's fault.