[Python-Dev] PEP 318, and the PEP process

["Martin v. Löwis"]

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:
- PEP champion writes the PEP, starts discussion
- PEP champion collects opinions, to avoid repeated
   discussion
- BDFL pronounces
- code gets written
- code gets checked in

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