> As I write Python 3 now, I am less than impressed with the reasons for breaking compatibility. I'm told that it was necessary for proper bug-free Unicode code

> As I write Python 3 now, I am less than impressed with the reasons for breaking compatibility. I'm told that it was necessary for proper bug-free Unicode code, but there's enough difficulty when using, say, gzip, and little enough documentation about the "proper" way to handle Unicode that I doubt that it will actually reduce Unicode-related bugs. This was absolutely essential. Python 2 tried to fix by introducing unicode type. It was hacky, and because they looked for a shortcut, they did a very bad thing by introducing implicit casting (so python 2 automatically converted between str and unicode). They did implicit casting because they didn't made the effort of fixing the stdlib to properly handle unicode. At that point not only there was a problem that str represent two different things (bytes and text), but also authors that were using unicode (to make their code futureproof) make their life actually harder (in python2 even when you know how unicode works, implementing it correctly is a minefield, it is so easy to do it incorrectly and end up with code that works, but blow in special circumstances). Python 3 basically decided to rip the bandaid off and do it correctly. And that's what happened. When you program in python 3 you no longer have to think much about unicode. To convert between byes you need to explicitly convert from text to bytes (.encode()) and bytes to text (.decode()) but this is not a concern unless you are doing some kind of serialization. While the breaking unfortunately was necessary (a lot of python 2 code, while it runs it is broken), I'm wondering if it was possible to do it a bit more developer friendly. I think things would be much easier if instead of changing the behavior of `str` type, Guido would introduce a `text` type (along with `bytes` type), then later deprecate it. I think that would help a lot. Although in that case modifying stdlib would be unavoidable, so it would be a lot of work for them. BTW: MyPy was also a tool that could help with the migration, but once again they IMO dropped a ball. Basically when MyPy is used in Python 2 mode, it follows Python 2 typing system, which means it still allows for implicit casting. I think what was really needed is to highlight these issues to allow for fixing python 2 code before doing the migration. The way mypy worked required you to first migrate your code to Python 3 and only after that you could start fixing the text/bytes issues.