python-checkins watchers would be aware that I just checked in a few
changes to the PEP 0 generator (and a few PEP statuses) to start
tidying up the first two sections of PEP 0. The old release schedule
PEPs and similarly obsolete files have been moved down to a new
historical section later in the document.
This was mostly straightforward and non-controversial, but I ran into
a problem with the Informational PEPs: we use the same status
("Final") to mean two completely different things for those PEPs.
For the release schedule PEPs it means "done and dusted" (similar to
the meaning for ordinary PEPs). For the API standardisation PEPs (like
WSGI) it instead means the spec has been locked down and any changes
will require a new PEP. This caused a problem for the PEP 0 generator,
since the former kind of PEP should be moved to the new historical
section, while the latter kind should remain up top.
Would anyone object if I switched all the API definition PEPs to the
"Active" state? PEP 1 indicates that is the appropriate state for
reference PEPs that are never truly "finished" (in the sense of code
being implemented and committed to the source control system).
In addition, I would like to mark PEP 42 as Withdrawn and PEP 3100 as
Final (the former is a random grab bag of feature requests better
handled via the tracker, while the latter is a similar py3k grab bag,
except we either did most of the things it lists or deliberately chose
not to)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
