I would disagree with that part. Forks are highly difficult. OpenBSD succeeded, so did the gcc fork that was sponsored by Cygwin but then merged back into mainline gcc. Otherwise?
Then, the council owns the entire marketing organization PSF, which owns the conferences, which means undesirables can and will be deplatformed.
It is much much harder to do a successful fork in 2024 than it was in 2005. Open source is corporate now, and the employees will stick with the official version and not the fork.
I think you could literally write an XPython fork that is 2 times faster, has a 100% compatibility but would still be marketed out of existence.
If Python had a free standard, it might be possible. But that will not happen.
- Python turned out to be annoyingly dynamic, in contrast with usual instincts. This meant that even CPython itself had to sacrifice some edge-case compatibility for every release.
- Moreover, Python C API was also hard to change without breaking some extensions, which are ironically why Python got popular in the first place! Many alternative mechanisms, notably HPy, were proposed but they all fell short of replacing the current C API. Nowadays CPython is more willing to get rid of as many internal but publicly exposed APIs as possible though.
- Python has a free standard, it's located at https://docs.python.org/ and is enough to implement something that resembles Python. You probably meant the sort-of-formal standard (which also mean many different things), but the mere existence of such "standard" doesn't mean anything, see: https://news.ycombinator.com/item?id=40519050
The discussion got heated but I think Tim Peters is arguing for a more stringent suspension rule as opposed to a simple majority vote. CoC violations are serious and should be debated better than just setting up a vote. The debate should be publicly discussed and the findings and reasons published as well.
Why is there opposition to that?