> in Mercurial's code base, most of our string types are binary by design: use of a Unicode based str for representing data is flat out wrong for our use case.

> in Mercurial's code base, most of our string types are binary by design: use of a Unicode based str for representing data is flat out wrong for our use case. I feel like this is the essence of the article: specific constraints/choices of Mecurial made their port to Python 3 difficult. Working with early Python 3 certainly did not help. But there seems to have been some stubbornness here mixed with a lot of retroactive justification. > One was that the added b characters would cause a lot of lines to grow beyond our length limits and we'd have to reformat code. This is almost ridiculous. You are going to write a JIT partial 2to3 instead of just increasing your length limits and/or using an autoformatter? (Of course, it turns out they eventually did do that... after a bit more stubborness regarding the autoformatter.) > So I'm not sure six would have saved enough effort to justify the baggage of integrating a 3rd party package into Mercurial. Couldn't this have been a very occasional copy and paste, instead of a downstream dependency? [six](https://six.readthedocs.io/ https://six.readthedocs.io/) "consists of only one Python file, so it is painless to copy into a project." > Initially, Python 3 had a rather cavalier attitude towards backwards and forwards compatibility. Yes, can't disagree. Early adopters who attempted to write 2- and 3- compatible code suffered the most.