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

Now this is a very dangerous situation, looking how perl5 was handled after Larry wall left them and stepped over to perl6.

Constant infighting of the core devs, useless communication on the mailing list, not a single worthwhile feature being implemented in 15 years, even if perl6 and Larry designed tons of them suitable for perl5, total destruction of the syntax and the core. The better counterexample was perl6 with stricter processes and some capable devs remaining, but still it's another minefield.

Good luck, tons of work to do. python 3 could get 10x faster and catch up to php7 or javascript, types could get properly integrated but I don't see it coming. Usually you have to expect the worst.

I think had it been a more clear demarcation, like this, Perl 5 would be in much better shape today. Perl 5 has been doing well for a few years now, but it took a while for the Perl 5 developer community to fill the void left by Larry; there just wasn't an acknowledgment that there was a void to fill. Larry didn't die, still kinda paid attention to Perl 5 for a while, but his heart wasn't in it and his attention eventually shifted fully to Perl 6.

Now, the Perl Pumpking (a sort of Benevolent Punching Bag for the Next Release; they do have the ability to decide which patches go in, but usually don't wield it like a dictator) along with the dev community, does their thing...the pumpkin gets passed along every year or three, and things continue. And, Perl 5 is developing nicely in a way that it didn't for about a decade while there was so much uncertainty. The Pumpking existed before Larry left Perl 5, but acted more in a support role (as I understand it), so it seems like it took a while for it to become an acknowledged executive position when Larry faded from view in Perl 5 development.

I think Guido is doing the best thing for Python. If his heart isn't in it, stepping back in a clear way is much more helpful that drifting away and leaving a void of leadership with no one feeling empowered to step up. There are people who are recognized as being contenders for the throne, and there's already a long-standing community process. I think Python will be fine.

Can tell you performance has never been an issue for me and python. Usually when I see the claim come up it is usually a poor test (ie "let's see how fast we can read from a database") or not knowing the performance options available to python. You can use pypy for JIT compilation performance. You can use eventlet to add co-operative threading / evented processing. Use multiprocessing if you want to use more than one core. The point of python is to optimize for human understanding 1st, and if your abstractions are good then you can enable extra performance with other libraries.

Regarding the endless mailinglist thread problem on this PEP, I can only recommend to use a different PEP tool.

A wiki leads to more structured argumentation, can be re-ordered and edited and doesn't get out of control. Sometimes I also use github issues, because I can update the issues there. But on big issues a wiki page is better.

Such a mailinglist discussion is mostly drama without much content.