Version control system maintainer let me down work on transferring the project from Python 2 to Python 3. Despite the fact that the first porting attempts were made back in 2008, and accelerated adaptation for working with Python 3 began in 2015, the full ability to use Python 3 was implemented only in latest branch of Mercurial 5.2.
Predictions about the stability of the port for Python 3 are disappointing. In particular, it is expected that random errors will pop up in the code over the course of several years, since tests do not cover 100% of the code base, and many problems are invisible during static analysis and only appear at runtime. In addition, many third-party add-ons and extensions remain untranslated to Python 3.
Since during the porting it was decided to gradually adapt the code to Python 3, while maintaining support for Python 2, the code acquired many hacks to combine Python 2 and 3, which will have to be cleaned up after support for Python 2 ends.
Commenting on the situation with Python 3, the Mercurial maintainer believes that the decision to promote the interoperability-breaking Python 3 and impose it as a new, more correct language, in the absence of breakthrough improvements relevant to developers, was a big mistake that caused great harm to the community and is an example of how not large projects need to do so. Instead of gradually building functionality and allowing applications to be incrementally customized, the release of Python 3 forced developers to rewrite code and spend resources maintaining separate branches for Python 2 and Python 3. It wasn't until seven years after the release of Python 3.0 that Python 3.5 introduced features to smooth out transition process and ensure that the same code base runs both Python 2 and Python 3.
Source: opennet.ru