mirror of
https://github.com/python/cpython.git
synced 2025-08-01 15:43:13 +00:00
Mark deprecated modules as such.
This commit is contained in:
parent
09a5c3e6bb
commit
7f758c49fa
14 changed files with 25 additions and 3 deletions
|
@ -79,6 +79,9 @@ As you can see, the module-specific markup consists of two directives, the
|
|||
The ``synopsis`` option should consist of one sentence describing the
|
||||
module's purpose -- it is currently only used in the Global Module Index.
|
||||
|
||||
The ``deprecated`` option can be given (with no value) to mark a module as
|
||||
deprecated; it will be designated as such in various locations then.
|
||||
|
||||
.. describe:: moduleauthor
|
||||
|
||||
The ``moduleauthor`` directive, which can appear multiple times, names the
|
||||
|
@ -333,6 +336,13 @@ the current module, or the built-in function of that name. In contrast,
|
|||
``:func:`foo.filter``` clearly refers to the ``filter`` function in the ``foo``
|
||||
module.
|
||||
|
||||
Normally, names in these roles are searched first without any further
|
||||
qualification, then with the current module name prepended, then with the
|
||||
current module and class name (if any) prepended. If you prefix the name with a
|
||||
dot, this order is reversed. For example, in the documentation of the
|
||||
:mod:`codecs` module, ``:func:`open``` always refers to the built-in function,
|
||||
while ``:func:`.open``` refers to :func:`codecs.open`.
|
||||
|
||||
A similar heuristic is used to determine whether the name is an attribute of
|
||||
the currently documented class.
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: md5
|
||||
:synopsis: RSA's MD5 message digest algorithm.
|
||||
:deprecated:
|
||||
|
||||
|
||||
.. deprecated:: 2.5
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: mimetools
|
||||
:synopsis: Tools for parsing MIME-style message bodies.
|
||||
:deprecated:
|
||||
|
||||
|
||||
.. deprecated:: 2.3
|
||||
|
|
|
@ -3,6 +3,7 @@
|
|||
|
||||
.. module:: MimeWriter
|
||||
:synopsis: Write MIME format files.
|
||||
:deprecated:
|
||||
|
||||
.. sectionauthor:: Christopher G. Petrilli <petrilli@amber.org>
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: mimify
|
||||
:synopsis: Mimification and unmimification of mail messages.
|
||||
:deprecated:
|
||||
|
||||
|
||||
.. deprecated:: 2.3
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: multifile
|
||||
:synopsis: Support for reading files which contain distinct parts, such as some MIME data.
|
||||
:deprecated:
|
||||
.. sectionauthor:: Eric S. Raymond <esr@snark.thyrsus.com>
|
||||
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: popen2
|
||||
:synopsis: Subprocesses with accessible standard I/O streams.
|
||||
:deprecated:
|
||||
.. sectionauthor:: Drew Csillag <drew_csillag@geocities.com>
|
||||
|
||||
|
||||
|
|
|
@ -7,6 +7,7 @@
|
|||
.. module:: posixfile
|
||||
:platform: Unix
|
||||
:synopsis: A file-like object with support for locking.
|
||||
:deprecated:
|
||||
.. moduleauthor:: Jaap Vermeulen
|
||||
.. sectionauthor:: Jaap Vermeulen
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: rfc822
|
||||
:synopsis: Parse 2822 style mail messages.
|
||||
:deprecated:
|
||||
|
||||
|
||||
.. deprecated:: 2.3
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: sets
|
||||
:synopsis: Implementation of sets of unique elements.
|
||||
:deprecated:
|
||||
.. moduleauthor:: Greg V. Wilson <gvwilson@nevex.com>
|
||||
.. moduleauthor:: Alex Martelli <aleax@aleax.it>
|
||||
.. moduleauthor:: Guido van Rossum <guido@python.org>
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: sha
|
||||
:synopsis: NIST's secure hash algorithm, SHA.
|
||||
:deprecated:
|
||||
.. sectionauthor:: Fred L. Drake, Jr. <fdrake@acm.org>
|
||||
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: stringprep
|
||||
:synopsis: String preparation, as per RFC 3453
|
||||
:deprecated:
|
||||
.. moduleauthor:: Martin v. Löwis <martin@v.loewis.de>
|
||||
.. sectionauthor:: Martin v. Löwis <martin@v.loewis.de>
|
||||
|
||||
|
|
|
@ -4,6 +4,7 @@
|
|||
|
||||
.. module:: xmllib
|
||||
:synopsis: A parser for XML documents.
|
||||
:deprecated:
|
||||
.. moduleauthor:: Sjoerd Mullender <Sjoerd.Mullender@cwi.nl>
|
||||
.. sectionauthor:: Sjoerd Mullender <Sjoerd.Mullender@cwi.nl>
|
||||
|
||||
|
|
|
@ -168,11 +168,11 @@ ZipFile Objects
|
|||
.. note::
|
||||
|
||||
If the ZipFile was created by passing in a file-like object as the first
|
||||
argument to the constructor, then the object returned by :meth:`open` shares the
|
||||
argument to the constructor, then the object returned by :meth:`.open` shares the
|
||||
ZipFile's file pointer. Under these circumstances, the object returned by
|
||||
:meth:`open` should not be used after any additional operations are performed
|
||||
:meth:`.open` should not be used after any additional operations are performed
|
||||
on the ZipFile object. If the ZipFile was created by passing in a string (the
|
||||
filename) as the first argument to the constructor, then :meth:`open` will
|
||||
filename) as the first argument to the constructor, then :meth:`.open` will
|
||||
create a new file object that will be held by the ZipExtFile, allowing it to
|
||||
operate independently of the ZipFile.
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue