[Python-Dev] Two small PEP ideas (original) (raw)

Guido van Rossum guido at python.org
Tue Apr 27 20:53:49 CEST 2010

On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw <barry at python.org> wrote:

I have two somewhat unrelated thoughts about PEPs.

* Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email.  I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted.  I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted.  I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147:  http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections.

I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like "last call for objections." There should also be a timeline so that unproductive discussion can't be dragged on forever.

* EOL schedule for older releases.

We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs.  However, we have release schedule PEPs going back to Python 1.6.  It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas.  We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically.

SGTM.

-- --Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list