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

"Martin v. Löwis" martin at v.loewis.de
Fri Aug 6 11:31:52 CEST 2004

Anthony Baxter wrote:

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.

Yes. However, we can learn, and correct earlier errors. This doesn't all need to happen before 2.4, but we could start.

For example, we could try listing issues with existing PEPs, and then ask the previous champions to deal with these issues. Responsiveness to such requests is an indication how responsible a contributor is.

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.

With Moshe Zadka and Guido van Rossum as champions.

Looking at PEP 237, I fail to see why people say the PEP is not up-to-date. According to the PEP, we should be in stage B1, and AFAICT, we actually are in stage B1. The last change to the PEP is from December 2003.

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.

This is IMO ok if the changes are "minor", where a minor change is one that doesn't deserve a PEP. Adding new functions or changing the precise conditions under which exceptions occur falls into this class.

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.

This is still not the process you described: no code had been checked in before. If the feature as described had been implemented before, then this change would have been a major change, and should not have been committed without a PEP of its own.

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

I'm not blaming anybody, and this is all understandable. We just have to find ways how to deal with the problem that nobody has time to really work on these things.

My view is: it is sometimes better nothing gets done, rather than something being done poorly. Of course, this view only applies to new features - for bug fixes, it is better to do something that fixes the bug (like ripping the feature out) rather than doing nothing.

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.

I don't think it is really that bad wrt. the current PEPs. Some of the issues I found are

Regards, Martin

More information about the Python-Dev mailing list