“I'm basically giving myself a permanent vacation from being BDFL”

> I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions.

Leading a large open source project must be terrible in this age of constant outrage :-(

I'm a little confused though, by his feelings here. Why did he feel the need to "fight so hard for a PEP" if it was so controversial, and everyone was outraged?

I do understand people's points about "the age of outrage" and "internet 2018" but still: the PEP wasn't generally accepted as being a fantastic improvement, so why did he feel the need to fight so hard for it?

It was controversial syntax, inline assignment-as-expression. There's always a tension between "keep it simple stupid" and "let's make it better", especially when a large user demographic of Python are non-professional-programmers.

Interestingly, C++ is going through the same process, with lots of great ideas being proposed, but the sum total of them being an even more complicated language (on top of what is probably the most complicated language already).

Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.

No, the bad decision was treating bytes and strings interchangeably in the first place. 99% of the hardest to fix breakage was due to that, and it was the right call to pay that price all at once.

The API in 2 is not optimal, but they fixed it the wrong way. As you know, some operations make sense with bytes, and some make sense with character strings. The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding. Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding. Whole classes of errors would just disappear for many python coders. Other coders, who do care about encodings and non-ASCII characters, would still get those errors but that would be OK because they would know how to fix those errors.

So yes some breaking change was indicated, but the particular change that was made was the wrong one.

> The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding.

That's the ruby solution. I like the ruby API here. When ruby introduced it in 1.9, it did cause similar upgrade pain, since you weren't used to having your strings tagged with an encoding, and suddenly they all kind of need to be if you want to do anything with them as strings-not-bytes.

As someone else noted would be the result, indeed the result was lots of "incompatible encoding" exceptions.

I think ruby actually has a pretty reasonable API here, but several years on, there are still _plenty_ of developers who don't understand it.

Sure, there are growing pains with any breaking change. Do you think the ruby 1.8 -> 1.9 transition went more smoothly than the python 2.7 -> 3.x... transition?

My impression is that it did, yes.