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

["Martin v. Löwis"]

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
- PEP 263 states that Python 2.4 should give an error
   if no encoding declaration is specified. I propose to
   move this to 2.5.
- PEP 322: we need to evaluate whether reversed is useless.
- PEP 237: CSV is implemented, why is it still Draft, and open?
- PEP 307: Likewise
- PEP 331: Likewise (although I probably still owe a review)

Regards,
Martin