PEP: 4
Title: Deprecation of Standard Modules
Version: $Revision$
Author: Martin v. Loewis <loewis@informatik.hu-berlin.de>
Status: Active
Type: Informational
Created: 1-Oct-2000

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.  The rationale for deprecating a module is also
    collected in this PEP.  If the rationale turns out faulty, the
    module may become `undeprecated'.


Procedure for declaring a module deprecated

    Since the status of module deprecation is recorded in this PEP,
    proposals for deprecating modules MUST be made by providing a
    change to the text of this PEP, which SHOULD be a patch posted to
    SourceForge, or sent by mail to the author of this PEP.

    A proposal for deprecation of the module MUST include the date of
    the proposed deprecation and a rationale for deprecating it.  In
    addition, the proposal MUST include a change to the documentation
    of the module; deprecation is indicated by saying that the module
    is "obsolete" or "deprecated".  The proposal MAY include a patch
    for the module's source code to indicate deprecation there as
    well.

    It is expected that deprecated modules are included in the Python
    releases that immediately follows the deprecation; later releases
    may ship without the deprecated modules.


Procedure for declaring a module undeprecated

    When a module becomes deprecated, a rationale is given for its
    deprecation.  In some cases, an alternative interface for the same
    functionality is provided, so the old interface is deprecated.  In
    other cases, the need for having the functionality of the module
    may not exist anymore.

    If the rationale is faulty, again a change to this PEP's text MUST
    be submitted.  This change MUST include the date of undeprecation
    and a rationale for undeprecation.  Modules that are undeprecated
    under this procedure MUST be listed in this PEP for at least one
    major release of Python.


Obsolete modules

    A number of modules are already listed as obsolete in the library
    documentation.  These are listed here for completeness.

    addpack, cmp, cmpcache, codehack, dircmp, dump, fmt, lockfile,
    newdir, Para, poly, regex, regsub, tb, timing, util, whatsound,
    tzmod, find, grep, packmail, ni, rand, soundex, cl, sv

    All these modules have been declared as obsolete in Python 2.0,
    some even earlier.


Deprecated modules

    Module name:   posixfile
    Rationale:     Locking is better done by fcntl.lockf().
    Date:          Before 1-Oct-2000.
    Documentation: Already documented as obsolete.

    Module name:   gopherlib
    Rationale:     The gopher protocol is not in active use anymore.
    Date:          1-Oct-2000.
    Documentation: TBD

    Module name:   audioop
    Rationale:     The module is not actively being used, no mentioning
                   of it was found on deja.com on Oct-1-2000.
    Date:          1-Oct-2000
    Documentation: TBD

    Module name:   rgbimgmodule
    Rationale:     The module is not actively being used, no mentioning
                   of it was found on deja.com on Oct-1-2000.
    Date:          1-Oct-2000
    Documentation: TBD


Undeprecated modules

    None.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
End: