[Python-Dev] Rewriting PEP4 (original) (raw)
"Martin v. Löwis" martin at v.loewis.de
Mon Dec 6 22:28:39 CET 2004
- Previous message: [Python-Dev] Deprecated xmllib module
- Next message: [Python-Dev] Rewriting PEP4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- a warning must be added to the module, indicating the expected version when the module is removed, and a reference to the PEP
- 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)
- 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
- Previous message: [Python-Dev] Deprecated xmllib module
- Next message: [Python-Dev] Rewriting PEP4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]