44 lines
1.4 KiB
ReStructuredText
44 lines
1.4 KiB
ReStructuredText
PEP: 4
|
|
Title: Deprecation of Standard Modules
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Brett Cannon <brett@python.org>, Martin von Löwis <martin@v.loewis.de>
|
|
Status: Active
|
|
Type: Process
|
|
Content-Type: text/x-rst
|
|
Created: 01-Oct-2000
|
|
Post-History:
|
|
|
|
|
|
Introduction
|
|
============
|
|
|
|
When new modules were added to the standard Python library in the
|
|
past, it was not possible to foresee whether they would still be
|
|
useful in the future. Even though Python "Comes With Batteries
|
|
Included", batteries may discharge over time. Carrying old modules
|
|
around is a burden on the maintainer, especially when there is no
|
|
interest in the module anymore.
|
|
|
|
At the same time, removing a module from the distribution is
|
|
difficult, as it is not known in general whether anybody is still
|
|
using it. This PEP defines a procedure for removing modules from the
|
|
standard Python library. Usage of a module may be 'deprecated', which
|
|
means that it may be removed from a future Python release.
|
|
|
|
|
|
Procedure for declaring a module deprecated
|
|
===========================================
|
|
|
|
To remove a top-level module/package from the standard library, a PEP
|
|
is required. The deprecation process is outlined in :pep:`387`.
|
|
|
|
For removing a submodule of a package in the standard library,
|
|
:pep:`387` must be followed, but a PEP is not required.
|
|
|
|
|
|
Copyright
|
|
=========
|
|
|
|
This document has been placed in the public domain.
|