[Python-Dev] Rewriting PEP4

["Martin v. Löwis"]

Brett C. wrote:
> And as for the mention of dropping PEP 4, I agree with the running 
> consensus that it isn't needed thanks to the warning module.  Do we need 
> to have a more formal vote to drop PEP 4, or should one the PEP 
> maintainers just delete it?

I would do what Barry suggests: rephrase the module to document the
deprecation/removal procedure. This, of course, needs
consensus/pronouncement, too, but I think I would put the following
aspects into it:

Requirements
============
Removal of module needs proper advance warning for users; the
module should be removed only if
- continued usage poses a security threat to the application
   using it, or
- there are no reported usages of the module anymore for quite
   some time
- the module is unmaintained (i.e. there are serious outstanding
   unfixed bugs for it), and there are alternatives which are
   maintained.
There must be a way for users to stop removal of the module,
e.g. by volunteering to maintain an unmaintained module.

Deprecation
===========
If a module is candidate for removal, it must be deprecated first.
In order to deprecate the module
1. a warning must be added to the module, indicating the expected
    version when the module is removed, and a reference to the PEP
2. a comment must be added just above the warning, giving a
    the date and version of deprecation, and a
    rationale for removal (e.g.: no known users, is security risk)
3. the module documentation must be removed from the Python
    documentation (alternatively: moved into a "deprecated" section)

Undeprecation
=============
A module can be undeprecated if the deprecation reasons turns out
to be invalid, e.g. if users of the module appear when the module
was believed to have no users, or if a maintainer shows up for a
previously unmaintained module. This fact must be recorded in the
module; the original state (documentation, no warning) be restored.

Removal
=======
If the module has been deprecated for atleast a year and atleast
a version, it can be removed. Removal should move it to old-libs
for pure Python modules; a removal procedure for pure C modules
has not been defined yet.

If the module was deprecated because it was unmaintained, the module
should only be removed if there have been no recent reports about
usage of the module.

Bug reports against deprecated modules
======================================
If a bug is reported against a deprecated module, the bug report
can be closed without further consideration, pointing to the
deprecation status. If a patch is submitted against the module,
it should be considered whether the patch could undeprecate
the module; if not, it can be rejected with the same rationale.

If this policy can be agreed, I will replace PEP4 with it.

Modules that have currently deprecation messages in them often
fail to identify the Python version in which removal will occur.
For modules that have been deprecated since 2.1, I would suggest
to remove them for 2.5, with the option of bringing them back
in 2.5.1 if people complain.

Regards,
Martin