It really seemed that the issue was mostly "Unicode is really hard if you haven't thought _deeply_ about it" because application code, library and framework code, _and_ "system" Python code had to go through several iterations of "here's how to do it right" before something reasonable came out that solved issues for most / all stakeholders. And the Swift / Raku people are still sitting on the sidelines smiling, knowing that there are a lot more "lenses" to view text through that Python doesn't make easy (but neither does Haskell, JS, or Java, so there's good company in good-enough-for-now land).

Most of the breaking changes did not justify upgrading.

I blame a lack of tools.

JS devs have been transpiling for years now and it works.

Python should have released a conversion tool that could automatically convert most stuff and identify the stuff it couldn't convert. This kind of directed upgrade would have made the process much easier for developers to actually accomplish.

I'm confused, because isn't that exactly what they did? What was wrong with 2to3?

https://docs.python.org/3/library/2to3.html

It didn't work well at all in my experience. Given how much code was thrown out rather than ported, I'm guessing that I'm not alone.

> Honestly I blame the community.

Sure. The point is that a community can make things go poorly, with or without a BDFL.

> The transition was slow

Here's the timeline the way I think about it:

- 2008-2012 Python 3 becoming usable (byte formatting, six library)

- 2012-2016 Libraries (Django, etc) becoming compatible

- 2016-today Applications (Trac, Ansible, Chrome, etc) becoming compatible.

It took a lot of time for the ecosystem to be ready. Yes, there was a lot of stubbornness, but that's reality.

There are many things that could have been done to make the transition go smoother.