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

[Anthony Baxter]

Martin v. Löwis wrote:
> 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.

This is a nice way to look at it. Unfortunately, we've
not honoured this much. I'm happy to say that we should
try and do this, but we have a significant issue with
un-updated PEPs.

>> 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).

A couple of people have commented that the int/long PEP,
for instance, is not up-to-date. I don't think this means
that the changes should be backed out.

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

Assuming the PEP can't be updated by then, sure. That
then suggests (to me) that the process should be that the
PEP should be updated to the state of the art before the
next release that includes the new features or behavior
(which was the first option in my original list).

In many cases, the process goes more like:

  - PEP is written
  - code is checked in
  - issues occur, code is updated, but PEP is not updated
    to match it.

In an extreme case, that's what's happened here - the basic
goal of the PEP is still there, but the syntax is completely
different, and a large chunk (class decorators) has been
removed. I suspect part of the problem is the sheer amount of
discussions on the topic, combined with decorator-fatigue on
the part of the people who could update it. (In my case, it's
mostly the former problem, combined with a lack of time).

>> 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.

Perhaps we need to collect a list of PEPs that are out-of-date,
and push really hard to get them brought up to date. I'd like
to see more use of the PEP status field in this way.


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.