Unicode has been seen as a threat to Python 3 success. “Python 3 trolls” used Unicode as the main reason to block Python 3 and stay at Python 2. Some popular members of the Python community were strong opponents of Python 3 and Unicode.
I know that Unicode is the right solution and I know that the implementation is very complex. It took many years to fix all small issues so that Python 3 now “just works”. People stopped to complain against Python 3, because we fixed the long list of the most common Unicode issues in Python.
I’m not sure that I would like to see the Python project driven by popular members of the Python community who don’t understand the deep technical issues.
I’m not sure that my example is the best one. I’m trying to explain that sometimes we have to break Python to make it evolve for the long term, but such changes would be very unpopular if you ask users if they want to break Python in the short term…
EDIT: I’m not saying that we must not listen to people outside Python core developers. We do listen to requests from popular projects, and we collaborate with them as much as possible
This is the point of the council in 8014 - to decide when the popular vote is irrelevant and the votes of those who are directly involved count for more in this particular circumstance.
Now that I phrase it like that, I’m a little afraid such a position would be indefensible, and there isn’t really a visibly fair way to produce an outcome like this. It’s hard enough getting the core developers to agree to an outcome like this already - perhaps it just can’t be done with any model other than an incredibly legitimate BDFL?
I’m sure that many people will disagree with the council in that case… How do you qualify that vote is relevant or not? Is there objective metrics to measure that?
I also see a risk of abusing this power. If the council doesn’t want a change, they can declare that the result of the vote is null because .
Taking unpopular decisions and the legitimately of the council/BDFL/whatever are problems with any kind of governance
Yeah, literally all the models have the issue. Therefore the aim in choosing one has to be maximising trust in whoever is selected. The N size of council is our main choice - do you have more trust in N=1 or N=3 or N=len(core_devs) or N=len(interested_parties) or …? After that, our ability to reject a council’s decision has to be evaluated. But the possibility of decisions we don’t agree with is the nature of the whole problem.
For me that makes PEP 8016 the equivalent of “Further Discussion … among 5 people”. Basically it says to me that we as a group can’t agree beyond that we need five other people to choose for us (i.e. “kicking the can down the road”).
And maybe that’s fine, but it does put those 5 people in a slightly precarious position because if people don’t like the governance choices those 5 make they will get the blame, versus the result of this vote which is universally all of our faults and thus not quite such a focused group to be grumpy at. And depending on how bitter you are, you can forever blame those 5 for whatever choice you don’t like based on whatever mechanism they choose.
Personally, my brain keeps going back and forth on PEP 8016 as whether I should expect it to be more like PEP 8011 with 5 people or 8014 without the requirement to interpret a vote.
All that aside, perhaps it’s time to post a reminder to vote by Dec. 16 on python-committers? (With a warning that reading the PEPs will take some time. :-))
the fact that I sense a general reluctance here that people think they need to form an opinion on everything (even though I don’t think that is the case for 8014).
I’m also interested in the intention of the Core Team Membership section, PEP 8016 – The Steering Council Model | peps.python.org, because that would address some of the issues I have with giving too much power to committers. Is there indeed an intention to add non-committing core team members?
