[Python-Dev] PEP 318, and the PEP process (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Fri Aug 6 09:26:34 CEST 2004

Anthony Baxter wrote:

I'm extremely averse to making the Python development process any heavier than it has to be

I think the original process (PEP1) goes like this:

So, in principle, the BDFL can only pronounce on what is in the PEP, however, that is not really important.

What is really important is that there must be a PEP champion all the time. Once the PEP champion loses interest, or goes away, the process stops here and now - irrespective of any code that has been written, or pronouncements the BDFL has made.

Having said that, I don't think the lack of completed PEP is a reason to back out the @ syntax from CVS.

I do firmly think this is sufficient reason. It means there is no champion for the PEP, so there can't be a new feature. In essence, the champion is the one who "controls" the feature, and who is in charge of making it work well. He is the one to complain to, and he will make sure issues get resolved (not necessarily resolving them himself).

I don't think the code needs to backed-out now; waiting for the next alpha would probably be enough.

There's also the issue that there's a bunch of other existing PEPs describing features that aren't up to date at all.

This is the same problem. Nobody will complain if it works out all nicely, but we can forget about the PEP process if we are not willing to bow to the rules. If we don't like the rules, we should losen them, or perhaps drop the PEP process altogether. However, just ignoring it is not acceptable.

I don't think we want to make the Wiki the primary copy of the document, but I think having the PEPs annotatable would be a win.

The easiest way to achieve this is to embed a Wiki link in each PEP.

Regards, Martin

More information about the Python-Dev mailing list