PEP 8012: Frequently Asked Questions

Committers
1

Why use the name “Expert” instead of “Working group”?

I used a name that is already in use, in the Experts Index which is part of the Dev Guide.

It is a bit more accurate than “Working Group” since some areas of interest will maybe only have one expert interested in them. But the two terms are very close in spirit.

What happens if there is no expert in a given area?

That part of the project will languish until there is interest to work on it. That’s the realistic answer. The alternative would be to force core developers with little experience in that given area to make decisions on it.

How often will committers have to vote?

PEP 8012 does not expect there to be many votes. PEP decisions will be made within self-organized expert teams, there is no formal committer-wide vote unless a core developer decides to block a PEP.

It is the PEP author’s responsibility to gather feedback from the entire community in a matter that is comprehensive and inclusive enough to avoid votes to reject PEPs.

It is the relevant expert team’s responsibility to make it clear to the PEP author long before they decide which way they are leaning towards so that the author has opportunity to make the PEP palatable.

The other votes are only to nominate or eject a core developer.

Why do you insist on votes through GitHub?

This is no different than the current mailing list -1/0/+1 but formalizes it so it’s easier to keep counts. Those are public right now, including when nominating a core developer.

Why do you require no -1 votes on new core developers?

The core team functions due to trust. Any core team member has tremendous fire power to do great harm to the project, both technically and politically.

If any existing member of the core team feels strongly enough to -1 a candidate, we should trust them. Maybe we can discuss and convince that person to drop the -1. Maybe the reasoning for the -1 is strong enough to hold off with the addition.

How does having self-organized working groups avoid “design by committee”?

PEP 8012 avoids voting when it’s not necessary. In areas of very wide and conflicting interest there will probably be many core developers taking part in discussions. The decision to accept a PEP must be signed off by all members of the given team. This promotes discussion prior to the final comment period.

Will this slow down radical changes to Python?

Yes, controversial ones. That’s not the worst thing to happen to a 30-year-old language, is it?

Does PEP 8012 allow it to be changed by the committers?

It doesn’t explicitly mention anything like that. If there is a need to overthrow the governance model entirely, it would require a “working group” to be formed around it which would consist of all core developers. They would likely use PEP 8001 as base for another round of proposals. Such motion could be bootstrapped by a vote to “reject PEP 8012”. If 2/3 of voters feel the model does not work, it’s uncontroversial to restart the search for a better one.

For small tweaks to the existing model, an update to the PEP or a follow-up PEP would be enough. An expert team around it would form to work on that. Any core developer strongly against the documented change would be able to raise a motion to vote to reject it, as per PEP 8012.

How is PEP 8012 compatible with PEP 8016?

PEP 8016 explicitly avoids discussing the PEP process, leaving this decision as part of the mandate of the steering council. In this light, PEP 8012 defines a possible design for a PEP process that could be adopted by the council.

PEP 8012’s entire goal was to show that with a strong enough decision process, the need for a “top of hierarchy” group can be avoided. PEP 8016 hopes that this group will exercise their powers responsibly and rarely. That will require a reform of the PEP process and PEP 8012 specifies a possible one.

2 Likes
2

(Sorry if this is a repeat of past discussions. I’ve been ignoring this thing to ward off recurring feelings of burn-out.)

This worries me though. While I understand this is meant to avoid another drama like assignment expressions, it would also prevent something as useful as decorators to be added to the language, and very likely it would end up blocking adding a match statement (there’s just no way we can make match a keyword, there are no other reasonable candidate keywords, and solutions like @match or $match would be too controversial). Essentially the language would stop evolving. I worry that that would make Python become the next legacy language rather than the language that everyone wants to use.

1 Like
3

It might be useful to look at how C++ does things. It’s an old language that places a lot of importance on compatibility, yet it has managed to evolve at a relatively high pace in the last 10+ years.

1 Like
4

I don’t think that the intent here is to stop any radical change. It’s just the worst risk that can happen. Sometimes, it takes time to mature an idea.

Maybe adding pattern matching wouldn’t be accepted at the first attempt, but accepted one year later, when enough people would have time to think about it and find use cases for it? I’m just making hypothesis. I don’t know how pattern matching would look like and how people would like it. I’m awaiting for your PEP :slight_smile:

2 Likes
5

JS has also made substantial changes (e.g. adding generators and async/await) through their distributed committee-based process, and they have much stricter backcompat restrictions than we do (e.g. they can’t add any new keywords, ever). It requires some compromises but they make it work. The PEP 8012 proposal is modeled closely on Rust, and they’ve made radical changes through their process.

I think it’s an unavoidable fact that any new process is going to slow down controversial changes, but “slow down” doesn’t mean “stop”, and good changes are not necessarily controversial :-).

2 Likes
6

My main question (or misgiving:-) about 8012 isn’t in here…

And that question is how to ensure that this working group structure doesn’t lead to balkanisation of the language. Well, that’s rather strong, but what I mean is: by giving the experts in a certain area lots of power in that area it may lead to tunnel vision where the impact on other areas is overlooked. Maybe tunnel vision or group think is a better term?

There are some expert areas such as packaging that operate in relative isolation (i.e. a packaging-related PEP will probably have few if any adverse effect on other areas of interest). But in other areas, like async IO or raw interpreter speed or ABIs, I can imagine PEPs that would be very beneficial for those specific areas but have a serious impact on all Python users.

1 Like
7

Good question, Jack!

All 80xx PEPs at some point reach a question of possible malice, be it intentional or unintentional. It seems like the preferred answer here is: we are all consenting adults and we expect other players to behave responsibly and with the future of Python in mind.

When a change to Python is suggested in form of a PEP, PEP 8012 puts the onus of gathering feedback from all affected parties on PEP authors. First of all that is the responsible thing to do but the authors are additionally nudged a bit in this direction to ensure that:

  • the relevant expert team will feel confident to eventually decide that discussion on the PEP has run its course and will proceed towards the final comment period; and
  • during the final comment period no other core developer will raise motion to reject the PEP via vote.

Same with the relevant experts. They will likely behave carefully enough on their own accord but they are gently reminded that if they don’t represent their area of interest well, the rest of the core team may raise to vote to take their “expert bit” away.

In other words, I hope that those rules will be enough for a group of well-intentioned participants to avoid balkanization of Python. Is this enough?

Now, there is a related question that fascinates me. For some reason none of the 80xx PEPs went there but I think we should do it very soon after the governance model is chosen. Without further ado:

What is the role of Zen of Python?

or: where do we put a list of things that should always be true about Python and a list of things that should never be true about Python?

I believe that a set of high-level design goals for Python should be explicit. This is especially true for a model like PEP 8012 where we give a lot of freedom to semi-independent experts.

PEP 20 is a great start. It is criticized by some of our most senior core developers for being overly poetic for such purpose. I don’t think that’s a big problem. The set of high-level truths we are looking for should necessarily be very generic, otherwise we might end up with 618 commandments which is a level of detail I don’t think we need or even can reach with sufficient clarity.

PEP 20 is also criticized due to Python not actually living up to the koans. Yeah, there’s plenty of implicit things going on, we rarely have just one obvious way to do a thing, and so on. Again, I don’t think that’s a big problem. I always thought the Zen is aspirational, it’s not an edict.

My personal feel though is that PEP 20 is not explicit enough about certain design goals that we might want to make sure are understood. To give you a few examples:

  • keep Python teachable to 12 year olds;
  • never require a build system to run a simple Python program;
  • keep Python programs that run correctly today running 5 years from now with no source changes required;
  • never rewrite well established third party libraries from scratch into the standard library.

…and so on. These are just examples I just made up now by the way. I am not ready or willing to argue about those now. The point is, that is the level of constitutional detail for the project that I think we should try to formalize. It would remove plenty of controversy from subsequent PEP discussions.

2 Likes
8

It looks like Rust’s teams are much higher-level – there’s no equivalent of an “async IO team” or “C ABI team”.

It looks like for them, the core code they ship is all covered by just 3 teams, plus a dedicated team for coordinating between other teams. So I guess that helps avoid tunnel vision :-):

  • Core team: overall direction of the project, subteam leadership, cross-cutting concerns
  • Language team: designing new language features
  • Library team: the Rust standard library, rust-lang crates, conventions, and ecosystem support
  • Compiler team: compiler internals, optimizations
    • The equivalent for Python would be an “interpreter team”, that includes interpreter implementation, optimizations, C API, etc.

There are also teams that work on things around the main code:

  • Infrastructure team: infrastructure supporting the Rust project itself: CI, releases, bots, metrics
  • Documentation team: ensuring Rust has fantastic documentation
  • Release team: tracking regressions, stabilizations, and producing Rust releases
  • Moderation team: helping uphold the code of conduct

And a bunch of teams that cover areas that Python core traditionally leaves to third parties: Dev tools team, Cargo team (equivalent of pip/setuptools), IDEs and editors team, Crates.io team (equivalent of PyPI), Community team, Rustdoc team (equivalent of Sphinx, Readthedocs).

I guess we’d probably want to be a bit more fine-grained, esp. since our stdlib is so big; I can imagine teams like async IO, IDLE, crypto, … but I guess if the async IO team wanted to make some substantial language or interpreter change, they’d need to run that by the appropriate team? Like PEP 525 would have needed to be reviewed by the async IO team, the language team, and maybe the interpreter team?

We already effectively split into lots of ad hoc teams for discussions, and then cross-cutting concerns are handled through people bringing stuff up on python-dev, writing PEPs, presentations at the language summit, etc. I guess that probably wouldn’t change?

1 Like
9

Interesting, I hadn’t interpreted your words in this way! That means that 8012 and 8014 are even closer than I thought, with the expert teams basically being the Council of Elders distributed over a number of expert teams. And of course the difference on core developers vs. the whole community.

10

Yeah! (I hearted the original post already, but this point deserves special mention).