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

Anthony Baxter anthony at interlink.com.au
Fri Aug 6 10:11:12 CEST 2004

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:

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.

More information about the Python-Dev mailing list