Mercurial’s journey to and reflections on Python 3

I&#x27;ve been involved in multiple non-trivial libraries and frameworks that supported both python2 and python3 for many years with the same codebase ... and it really wasn&#x27;t anything like this. The python3 &quot;adaptation&quot; effort for mercurial was just bungled by multiple terrible decisions.<p>First was the idea that normal feature contributors should not see any b&quot;&quot; or any sign of python3 support for the first couple years of the effort. Huge mistake. You need some b&quot;&quot;.<p>But you don&#x27;t need all b&quot;&quot; everywhere. That was the second huge mistake. Don&#x27;t just convert every natural string in the whole codebase to b&quot;&quot;. The natural string type is the right type in many places, both for python2 (bytes-like) and python3 (unicode-like). The helpers for converting kwargs keys to&#x2F;from bytes is a sign that you are way off track. This guy got really hung up on the fact that the python2 natural string type is bytes-like, and tryied to force explicit bytes everywhere (dict keys, http headers, etc) and was really tilting at windmills for most of these past 5 years.<p>Yes, you pretty much had to wait for python-3.4 to be released and for python-2.6 to be mostly retired in favor of python-2.7. Then, starting in early 2014, it was pretty straightforward to make a clean codebase compatible with python-2.7 and python-3.4+, and I saw it done for Tornado, paramiko, and a few other smaller projects.

I understand author&#x27;s reasoning in the context of a transition, but as a &quot;non-Latin&quot; language user, defaulting str to unicode literals is the best change in Python 3. Coming from C#, I never get used to Python 2&#x27;s approach. It&#x27;s a pain in the ass working with non-Latin characters in Py2 starting from simply output in console, especially on Windows.<p>&gt;assuming the world is Unicode is flat out wrong<p>True, but Py2&#x27;s approach makes lots of developers assume the world is Latin-1. I see <i>way</i> too many examples of things broken on a Chinese locale environment, including Python&#x27;s official IDLE ([1]).<p>[1] <a href="https:&#x2F;&#x2F;bugs.python.org&#x2F;issue15809" rel="nofollow">https:&#x2F;&#x2F;bugs.python.org&#x2F;issue15809</a> (Summary of this bug: in 2.x IDLE, an explicit unicode literal used to still be encoded using system&#x27;s ANSI encoding instead of, well, unicode.)

&gt; in Mercurial&#x27;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.<p>I feel like this is the essence of the article: specific constraints&#x2F;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.<p>&gt; One was that the added b characters would cause a lot of lines to grow beyond our length limits and we&#x27;d have to reformat code.<p>This is almost ridiculous. You are going to write a JIT partial 2to3 instead of just increasing your length limits and&#x2F;or using an autoformatter? (Of course, it turns out they eventually did do that... after a bit more stubborness regarding the autoformatter.)<p>&gt; So I&#x27;m not sure six would have saved enough effort to justify the baggage of integrating a 3rd party package into Mercurial.<p>Couldn&#x27;t this have been a very occasional copy and paste, instead of a downstream dependency? [six](<a href="https:&#x2F;&#x2F;six.readthedocs.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;six.readthedocs.io&#x2F;</a>) &quot;consists of only one Python file, so it is painless to copy into a project.&quot;<p>&gt; Initially, Python 3 had a rather cavalier attitude towards backwards and forwards compatibility.<p>Yes, can&#x27;t disagree. Early adopters who attempted to write 2- and 3- compatible code suffered the most.

&gt; <i>Matt knew that it would be years before the Python 3 port was either necessary or resulted in a meaningful return on investment (the value proposition of Python 3 has always been weak to Mercurial because Python 3 doesn&#x27;t demonstrate a compelling advantage over Python 2 for our use case). What Matt was trying to do was minimize the externalized costs that a Python 3 port would inflict on the project. He correctly recognized that maintaining the existing product and supporting existing users was more important than a long-term bet in its infancy.</i><p>Having just done transitions on a number of much smaller projects I had the same thought. Changes to string handling tripped me up and the changes to relative imports took some thinking. But the biggest frustration was the nagging question: <i>Why am I doing this?</i><p>edit: missing word

It’s funny, on the Mac one becomes used to constant changes, rewriting damn near everything just to stand still. Yet I designed my Mac app long ago to depend on the system “Python 2” (bound to C++), because it seemed that both the installation itself and the Python language and libraries were very stable. Looking back, this turned out to be sustainable for a remarkably long time, as “Python 2” really did evolve only additively and there was almost no reason to even touch 15-year-old code that was relying on Python 2. For the Mac platform especially, this reliability is unheard of.<p>More amazing to me is that in Catalina, the release famous for breaking just about everything else, “Python 2” is still there and works as it always has! Of course, Apple did announce that it will be ripped out in the next release. :)

I have never seen such rejection in Django community, despite real problems, like with WSGI design, handling I&#x2F;O and thus working with bytes a lot.<p>Every huge task, like porting from Python 2 to Python 3 or any other huge task is either everybody&#x27;s task or just a small group&#x27;s one. And since latter seems more reasonable to not interfere with ongoing development, former is the only way I have seen such tasks to succeed.<p>Artificial rules to create comfort for one group at the expense of another group, like the following<p>&gt;&gt; This ground rule meant that a mass insertion of b&#x27;&#x27; prefixes everywhere was not desirable, as that would require developers to think about whether a type was a bytes or str, a distinction they didn&#x27;t have to worry about on Python 2 because we practically never used the Unicode-based string type in Mercurial.<p>sound pretty much wrong to me.<p>If there is a pain, it should become everybody&#x27;s pain, or otherwise people will simply burn out and hate own work, like the author did. There is no way porting to Python 3 can be harder than porting to Rust. Rust is statically typed and not garbage collected. Everyone would have to think if they need string or array of bytes anyway, but also, who owns them.<p>Overall, described situation looks like management issue and not a technical one to me.<p>Edit: typos.

We are on the brink of completing the transition to python3 at my work.<p>The end result of this is that I just spent a good chunk of last week reviewing a pull request with 70,000 lines of changes, which was one of the final in a series of ~10k line pull requests that came in through the fall.<p>All of this was the heroic effort of one of my coworkers who had the unenviable task of combing through our entire codebase to determine &quot;This is unicode. This is bytes. Here is an api boundary where we need to encode &#x2F; decode.&quot; etc.<p>It was a nightmare of effort that I&#x27;m glad to have behind us.

The biggest problem with the Python 2 to Python 3 transition was not that breaking changes were made. It’s that breaking changes were made in a way such that you could not easily have code that worked both on Python 2 and Python 3.<p>It took years before the advent of six, Python 3 u’’ literals, and modernize. The author discusses this at length.

&gt; <i>Perhaps my least favorite feature of Python 3 is its insistence that the world is Unicode. [..] However, the approach of assuming the world is Unicode is flat out wrong and has significant implications for systems level applications (like version control tools).</i><p>Isn&#x27;t this more a problem with Python not easily differentiating between String and Byte types? Both Go and Rust (&quot;&quot;&quot;systems&quot;&quot;&quot; level languages) have decided that &quot;utf-8 ought to be enough for anybody&quot; and that seems to be a good decision.

Having worked in python for about a decade, first in python2 and lately in python3, and having seen projects convert, I find this article baffling. I found Six to work pretty well, and where it didn&#x27;t it wasn&#x27;t hard to change.<p>I think the core error here was in NOT doing what he calls a &quot;flag day&quot; conversion. Sometimes it is easier to do something quickly, than to live with it happening slowly. I&#x27;ve done &quot;flag day&quot; conversions, and they were pretty painless, if stressful at the time.

The approach of doing the transition slowly over many years maybe was a mistake here, and another thing making it harder seems to have been little support from the top of the project.<p>I ported two projects with ~200000 Python-SLOC (about the same size as Mercurial according to sloccount) back in the early 3.x days. Doing this via more or less flag-day conversions within a few months, converting the codebases first to 2to3-able subset, and as a second step later on dropping 2to3 via common dialect of Python 2&#x2F;3 with six, was not very painful in the end.

I can&#x27;t believe their leadership de-prioritized the port until the last minute when they have an ecosystem on top of them that also has to port. I feel that was irresponsible.<p>The project lead said to not push `b&quot;&quot;` on people. That was a mistake imo that led them down a very frustrating rabbit hole (transformers, `pycompat`) that probably greatly extended their port time. One reason given is to not confuse devs with those details but they are critical details and ones you can&#x27;t avoid with Rust. This inconsistency makes me wonder if the post is mostly misdirected frustration. A lot of it centers on.<p>I agree about the early python3 releases making it harder. I don&#x27;t remember what the python leadership&#x27;s intent was but i think I actually agree with what they did, now. Over my career, I&#x27;ve come to appreciate starting with the ideal and working backwards. This let&#x27;s you learn what is needed rather than wasting time on speculation (planning or dev) or making a more crippled product.<p>I can understand frustrations with bugs &#x2F; differences in python versions. I ran into that a lot just within `2.7.*`<p>In my mind, the most notable complaint is the stdlib&#x27;s mixed efforts in supporting str or bytes. I feel &quot;batteries included&quot; maked this harder. They had to port a lot. Not everything can get the same level of scrutiny, especially from domain experts that represent a variety of use cases. They also can&#x27;t break compat. If they weren&#x27;t battries included, the porting efforts would be more directed, pull in the right people, and you can fix things later if you get it wrong.<p>What I find interesting is how different our experiences are that lead to the same place. My frustrations with python are rooted in build tools and packaging and have been loving Rust.<p>EDIT: I&#x27;m also surprised at the hostility towards distribution packagers. Instead of working with them to find mutually valid solutions, the express frustration at distributions and cripple themselves in not allowing third-party dependencies.

I think my takeaway lesson is that it’s very hard to introduce large, breaking changes to a language and not alienate a large proportion of existing users. I don’t know that there’s a right way.<p>I look at Perl, which was a juggernaut when I first used Python, and announcements of Perl 6 certainly didn’t help Perl’s slide. Often cited is the fact that Perl 6 is a <i>totally</i> different language unrelated by anything but creator and name. The Perl brand was not enough to carry the bulk of Perl users from Perl 5 to Perl 6. Perl 6 is now called Raku, which probably better reflects the magnitude of the change.<p>On the other hand Python 3 is a small but still significant departure from Python 2. If they’d called Python 3 something else, we’d probably be griping about how superficially different from Python 2 it was without bringing substantially new ideas.<p>Oddly my feeling is that Racket, in its departure from mainline Scheme, largely did retain its core audience, but that may have been a feature of its usage in academia.<p>Fast forward to last year when a prominent Racket architect announced “Racket 2” which would completely change the syntax of the language. Prominent community members reacted negatively, due to fears of Perl 6’s fate. But now they’ve decided to simply call the new research language Rhombus and have reiterated plans to continue supporting Racket. I went from feeling very negative to the change to being okay with the direction.<p>I’m not sure there are lessons to draw, other than noting than version bumping versus making a new language with a new name can be bad for entirely different reasons.

In the past I have been a vocal advocate for the way the transition from Python 2 to Python 3 was handled. However, it should be said I use Python primarily as scripting glue, e.g. for build scripts and automation tasks. I have never worked on a &quot;large&quot; Python code base nor did I have to migrate anything. Almost everything I had written in Python 2 was just naturally replaced by newer scripts in the due course of time.<p>I also remember my first forays into Python 3 and the annoyance I had at some of the decisions. I recall when they relented on the % operator for string interpolation and I agree it was a poor initial choice to leave it out. I totally agree with the author that Python 3 could have made some subtle changes earlier on to help those with massive codebases.<p>And I still feel it was the right move. Somehow Python is even more relevant today than it was when this painful process began. While some may say that popularity is despite missteps I actually believe the general slow and cautious push forward is one of the primary reasons Python continues to succeed. There is a balance between completely abandoning old users (e.g. Perl 5 to Perl 6) and keeping every historical wart (e.g. C++). IMO, the Python community found a middle ground and made it work.

There’s no doubt that the 2 -&gt; 3 transition was rough for the Python community. I personally stopped using Python as my go-to language in the early Python 3, since writing Python 2 code felt stupid since it was outdated the moment you wrote it, and 3 wasn’t really well supported by the community and tooling yet.<p>On the other hand, Python adoption has really taken off since Python 3.5-ish. Python has never been more popular.<p>So while you may wonder what might have been, had the transition been smoother, it’s hard to argue that Python 3 is a failure. All’s well that ends well, I guess?<p>Although it’s sad that Guido felt the need to step down. It’ll be interesting to see where Python goes this decade, now the transition is over and there’s a wealth of possibilities in front of it.<p>I expect there’ll be a lot of people looking to replace JavaScript with Python once you can run it in the browser with WASM.

It mostly makes me question the wisdom of implementing such a tool in Python in the first place - if you want low level access to raw underlying representations etc, using a super high level scripting language seems like a &quot;wrong tool for the job&quot; scenario. I am sure on the other hand they got a lot of productivity benefits from doing that, which is great, but having taken that tradeoff I don&#x27;t think it is fair to &quot;sour&quot; on a language when you clearly applied it out of it&#x27;s domain and then encountered problems due to that.

Not what you want to hear about a version control system: &quot;Python is a dynamic language and there are tons of invariants that aren&#x27;t caught at compile time and can only be discovered at run time. These invariants cannot all be detected by tests, no matter how good your test coverage is. This is a feature&#x2F;limitation of dynamic languages. Our users will likely be finding a long tail of miscellaneous bugs on Python 3 for years.&quot;

&gt; One of the biggest early hurdles in our porting effort was how to overcome the string literals type mismatch between Python 2 and 3. In Python 2, a &#x27;&#x27; string literal is a sequence of bytes. In Python 3, a &#x27;&#x27; string literal is a sequence of Unicode code points. These are fundamentally different types. And in Mercurial&#x27;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. We knew that Mercurial would need to eventually switch many string literals from &#x27;&#x27; to b&#x27;&#x27; to preserve type compatibility. But doing so would be problematic.<p>&gt; In the early days of Mercurial&#x27;s Python 3 port in 2015, Mercurial&#x27;s project maintainer (Matt Mackall) set a ground rule that the Python 3 port shouldn&#x27;t overly disrupt others: he wanted the Python 3 port to more or less happen in the background and not require every developer to be aware of Python 3&#x27;s low-level behavior in order to get work done on the existing Python 2 code base. This may seem like a questionable decision (and I probably disagreed with him to some extent at the time because I was doing Python 3 porting work and the decision constrained this work). But it was the correct decision. Matt knew that it would be years before the Python 3 port was either necessary or resulted in a meaningful return on investment (the value proposition of Python 3 has always been weak to Mercurial because Python 3 doesn&#x27;t demonstrate a compelling advantage over Python 2 for our use case).<p>As a general rule, this seems like good practice, but surely b-strings, print_function, etc are a trivial upfront cost, and one that would have to be paid sooner or later anyway?

A lot of Mercurial&#x27;s issues would have been resolved much easier if they&#x27;d used the common tools for maintaining polyglot 2&#x2F;3 code instead of trying to invent everything themselves.<p>Futurize and Pasturize in particular provide essentially all of the features that this post laments missing.<p><a href="https:&#x2F;&#x2F;python-future.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;python-future.org&#x2F;</a>

I guess this is as good a time as any to pimp my work in this area: <a href="https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;lib3to6&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pypi.org&#x2F;project&#x2F;lib3to6&#x2F;</a><p>lib3to6 is a Python compatibility library similar to to BableJS. It translates (most) valid Python 3.7 syntax to valid Python 2.7 and Python 3 syntax (aka. universal python). If you would like to develop with a modern python version and yet still maintain backward compatibility or if you want to bring a legacy codebase forward step by step (my use case), then please have a look.

We just migrated a big codebase to python 3 in about a year. It was not easy, but also not super hard with tools like futurize, and mypy.<p>Gladly we already had mypy hints, this helped us find a lot of mistakes when (not) using bytes.<p>Now we&#x27;re on python 3 we&#x27;re auto-migrate the type hints to be inlined with tools, like com2ann <a href="https:&#x2F;&#x2F;github.com&#x2F;ilevkivskyi&#x2F;com2ann" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ilevkivskyi&#x2F;com2ann</a> And we&#x27;re auto rewriting code to be more python 3 like with libcst and custom codemods...

It&#x27;s interesting that they wanted to add b&#x27; prefixes to all strings, and I wonder if they would have had a better experience by embracing regular strings instead. At least in Python 3, if your string only contains ASCII, then the underlying representation will use one byte per character, so ASCII-only strings are stored just as efficiently as ASCII-only bytes instances.<p>I think there are two mental models for how to approach the str&#x2F;bytes split:<p>1.) A `str` is for unicode use cases, and a `bytes` is better for cases that don&#x27;t support unicode.<p>2.) A `bytes` is an array of numbers between 0 and 255. A `str` should almost always be used when your value is conceptually a sequence of characters. `str` doesn&#x27;t imply that arbitrary unicode is allowed, and it&#x27;s fine to have a convention that a particular `str` is ASCII-only, just like other conventions you might have on variable values.<p>My impression is that #1 is the Python 2 mental model and is tempting for Python 3, but that #2 often works better when writing Python 3 code. Under mental model #2, asking for &quot;%s&quot; formatting is really asking for a replacement strategy that detects the number 37 followed by the number 155 in an array of numbers and fills in a sub-array, which seems more strange and likely to get false positives if you&#x27;re really working with binary data like the bytes of a .jpg file.<p>That said, I&#x27;m sure the devil is in the details, and maybe a project like mercurial has to stay backcompat with bytes data that is neither ASCII nor valid UTF-8, or some other compelling reason to stick with bytes everywhere.

I wish more devs cared about backward compatibility not just in python but in general. I know a particular, very popular library, 60k stars on github, who&#x27;s maintainers break stuff every month. They don&#x27;t care how many developers time it wastes they just decide FooBar should really be named FooB and rename it. No Effs given how many people it disrupts. You&#x27;d think people would complain but cult of personality and&#x2F;or popularity of library turns people in to fan boys where they seem to think &quot;If these geniuses are doing it this way then it must be good&quot;. .... sigh

For me this is the most exciting outcome:<p>&gt; The only Python 3 feature that Mercurial developers seem to almost universally get excited about is type annotations. We already have some people playing around with pytype using comment-based annotations and pytype has already caught a few bugs. We&#x27;re eager to go all in on type annotations and uncover lots of dynamic typing bugs and poorly implemented APIs.<p>Over in perl land people still spill their hate on types, which caused hard forks.

This criticism of the dev team seems naïve, &quot;It should not have taken 11 years to get to where we are today.&quot; Core developers can make tooling available, but they can&#x27;t control adoption. That is a user decision. Users switch-over on a timetable governed by their own individual cost-benefit analysis.

I wonder how many human lives&#x27; worth of work has been wasted from the decision to use Python and having to deal with 2&#x2F;3 transitions, and if it was worth it for the speedup of using an interpreted language.

Not knowing really anything about Mercurial, the `skip-blame` feature seems interesting, but seems Git doesn&#x27;t have something similar (has to be constrained <i>when</i> calling `blame`)

It would probably be less painful and much better (for other reasons) to migrate to some other language. Some projects did that successfully, or are in the process of doing so. Most notably reposurgeon: <a href="https:&#x2F;&#x2F;gitlab.com&#x2F;esr&#x2F;reposurgeon" rel="nofollow">https:&#x2F;&#x2F;gitlab.com&#x2F;esr&#x2F;reposurgeon</a>

For such a thorough article, I wish there were mention of Python 4

1. Introduce a new version with the plan of discontinuing the previous version <i>11 years</i> later (that&#x27;s almost half of the time that, by then, python had been a thing), that itself was released only three years after the very tool you&#x27;re talking about was released.<p>2. Don&#x27;t even pretend to be interested in trying to do a migration until seven years later.<p>3. Make sure that your migration plan includes a development cycle that&#x27;s deliberately hostile to the migration process.<p>4. ?<p>5. How could the <i>python maintainers</i> do this to <i>us</i>.<p>The description of the migration process was a good read. The fud afterwards... wasn&#x27;t.<p>And there were a few inaccuracies (I&#x27;m being charitable, some of them were straight up lies).<p>&gt; Python 3.0 was released on December 3, 2008. And it took the better part of a decade for the community to embrace it.<p>False, I&#x27;ve been using python 3, python 3 <i>exclusively</i>, since 2014, for all my projects.<p>&gt; Yes, Python is still healthy today and Python 3 is (finally) being adopted at scale<p>False, same as above.<p>&gt; I am ecstatic the community is finally rallying around Python 3<p>Again, false. Not only did &quot;the community&quot; rallied around python 3 years ago, he isn&#x27;t really happy about it, but I&#x27;ll get to that later.<p>&gt; For nearly 4 years, Python 3 took away the consistent syntax for denoting bytes&#x2F;Unicode string literals.<p>Or, to put it another way, python 3 was compatible with python 2&#x27;s string types almost eight years before python 2 reached end of life.<p>&gt; An ecosystem that falters for that long is generally not healthy<p>This entire paragraph was a hypothetical. It seems he really wanted to criticize something that did <i>not</i> happen.<p>&gt; The only language I&#x27;ve seen properly implement higher-order abstractions on top of operating system facilities is Rust<p>And here&#x27;s where his true point becomes evident: this is a hype piece for a language he found that he likes better. He&#x27;s just attacking something in his previous language that he thinks is valid just as an attempt to highlight why the new toy is truly better. In short: He felt like complaining about the migration would be a good way to proselytize.<p>Just in case: no, it isn&#x27;t better, and I say this as someone who currently isn&#x27;t using python nor rust. I&#x27;m using a language that I&#x27;m quickly growing to hate more than I do either of them at their worst (no, it&#x27;s not JavaScript).<p>&gt; if Rust were at its current state 5 years ago, Mercurial would have likely ported from Python 2 to Rust instead of Python 3. As crazy as it initially sounded, I think I agree with that assessment.<p>So... The best he can say about rust is that it might be better than python 3 five years ago that, by his own opinion on everything he wrote before this, was terrible? Well, that&#x27;s a recommendation <i></i>not<i></i> to use rust if I ever saw any.<p>When a hype piece defeats its own point.<p>&gt; And speaking as a maintainer, I have mad respect for the people leading such a large community.<p>No, he doesn&#x27;t; he used several appeals to emotion beforehand to try to paint them as terrible people.<p>&gt; It should not have taken 11 years to get to where we are today.<p>This statement by itself is a truism that doesn&#x27;t really mean anything, but the implication is that python 3 is only worthwhile 11 years later and it took that long for it to be so I&#x27;ll reply to <i>that</i>.<p>No, it didn&#x27;t. It didn&#x27;t even take that long for mercurial, they started the migration four and half years ago, not eleven.<p>&gt; am confident it will grow stronger by taking the time to do so<p>What is it to him? He should just move on to rust and be happy with it (sure, there are many people unhappy with it, but he wouldn&#x27;t take the effort to proselytize if he wasn&#x27;t).<p>In conclusion, I just don&#x27;t understand the need to tear something else down to prop up a new thing. I&#x27;m sure I would have liked a post about things he could do with rust, but now...

Python 3 is the new Windows Vista.

The transition from Python 2 to 3 was one worst things that could happened to the whole community. The costs of the transition never justified the benefits. The new features were negligible at best or a regression at worst and in some cases performance got even worse. One could even assume flat out sabotage.<p>Let&#x27;s just hope there will never be a Python 4 and the developers now finally start focusing on the greatest flaw of Python: performance.

Ok, yeah, maybe mercurial&#x27;s case was special, but still, this seems like they made it harder on themselves needlessly.<p>&gt; One was that the added b characters would cause a lot of lines to grow beyond our length limits and we&#x27;d have to reformat code<p>ORLY?! Well, guess what: hard line size limits are stupid. Now you know why.<p>That&#x27;s why &quot;foolish consistency is the hobgoblin of little minds&quot; is one of the 1st phrases of PEP-8.<p>But I&#x27;m tired of people saying &quot;oooh let&#x27;s cut all lines to be under 80-characters&quot; like it&#x27;s some kind of Biblical Mandate. No, it isn&#x27;t. And the 80 chars limit is BS. Probably the part I hate the most about PEP-8 (and especially how people interpret the PEP-8)<p>&gt; is its insistence that the world is Unicode<p>Oh please. Yes, the world is Unicode. Get over it. Maybe not bytes on disk&#x2F;network. But apart from that? Yes. If libraries take bytes or unicodes I can agree it&#x27;s a thorny issue, but let&#x27;s move on because a happy day is a day where I don&#x27;t get an UnicodeDecodeError because Python2, to add insult to the injury thinks the world is not only not Unicode, but it&#x27;s all ASCII.<p>Windows made the right call a long time ago when it decided to make all strings Unicode. Ok, maybe UTF-8 would be better than 16, but it still does the job.<p>But I have to agree with them that any version &lt; Py3.4 or 3.5 was really not worth it.