Anonymous avatar Anonymous committed 456955b

Remove redundant section titles after :ref:s.

Comments (0)

Files changed (69)

Doc-26/c-api/concrete.rst

 
 .. index:: single: PyBufferProcs
 
-More information on the buffer interface is provided in the section "Buffer
-Object Structures" (section :ref:`buffer-structs`), under the description for
-:ctype:`PyBufferProcs`.
+More information on the buffer interface is provided in the section 
+:ref:`buffer-structs`, under the description for :ctype:`PyBufferProcs`.
 
 A "buffer object" is defined in the :file:`bufferobject.h` header (included by
 :file:`Python.h`). These objects look very similar to string objects at the

Doc-26/c-api/newtypes.rst

 .. cmember:: PyBufferProcs* PyTypeObject.tp_as_buffer
 
    Pointer to an additional structure that contains fields relevant only to objects
-   which implement the buffer interface.  These fields are documented in "Buffer
-   Object Structures" (section :ref:`buffer-structs`).
+   which implement the buffer interface.  These fields are documented in
+   :ref:`buffer-structs`.
 
    The :attr:`tp_as_buffer` field is not inherited, but the contained fields are
    inherited individually.

Doc-26/extending/extending.rst

    }
 
 This function must be registered with the interpreter using the
-:const:`METH_VARARGS` flag; this is described in section :ref:`methodtable`,
-"The Module's Method Table and Initialization Function."  The
+:const:`METH_VARARGS` flag; this is described in section :ref:`methodtable`.  The
 :cfunc:`PyArg_ParseTuple` function and its arguments are documented in section
-:ref:`parsetuple`, "Extracting Parameters in Extension Functions."
+:ref:`parsetuple`.
 
 The macros :cfunc:`Py_XINCREF` and :cfunc:`Py_XDECREF` increment/decrement the
 reference count of an object and are safe in the presence of *NULL* pointers
 (but note that *temp* will not be  *NULL* in this context).  More info on them
-in section :ref:`refcounts`, "Reference Counts."
+in section :ref:`refcounts`.
 
 .. index:: single: PyEval_CallObject()
 

Doc-26/install/index.rst

 .. % end{latexonly}
 
 
-.. _intro:
+.. _inst-intro:
 
 Introduction
 ============
 the Distributing Python Modules (XXX reference: ../dist/dist.html) manual.
 
 
-.. _trivial-install:
+.. _inst-trivial-install:
 
 Best case: trivial installation
 -------------------------------
 modules from standard source distributions.
 
 
-.. _new-standard:
+.. _inst-new-standard:
 
 The new standard: Distutils
 ---------------------------
 get out of this manual.
 
 
-.. _standard-install:
+.. _inst-standard-install:
 
 Standard Build and Install
 ==========================
 
-As described in section :ref:`new-standard`, building and installing a module
+As described in section :ref:`inst-new-standard`, building and installing a module
 distribution using the Distutils is usually one simple command::
 
    python setup.py install
 a :command:`Terminal` window to get a shell prompt.
 
 
-.. _platform-variations:
+.. _inst-platform-variations:
 
 Platform variations
 -------------------
    python setup.py install
 
 
-.. _splitting-up:
+.. _inst-splitting-up:
 
 Splitting the job up
 --------------------
 you'll run lots of individual Distutils commands on their own.
 
 
-.. _how-build-works:
+.. _inst-how-build-works:
 
 How building works
 ------------------
    python setup.py build --build-base=/tmp/pybuild/foo-1.0
 
 (Or you could do this permanently with a directive in your system or personal
-Distutils configuration file; see section :ref:`config-files`.)  Normally, this
+Distutils configuration file; see section :ref:`inst-config-files`.)  Normally, this
 isn't necessary.
 
 The default layout for the build tree is as follows::
 of installing Python modules and applications.
 
 
-.. _how-install-works:
+.. _inst-how-install-works:
 
 How installation works
 ----------------------
 
 If you don't want to install modules to the standard location, or if you don't
 have permission to write there, then you need to read about alternate
-installations in section :ref:`alt-install`.  If you want to customize your
-installation directories more heavily, see section :ref:`custom-install` on
+installations in section :ref:`inst-alt-install`.  If you want to customize your
+installation directories more heavily, see section :ref:`inst-custom-install` on
 custom installations.
 
 
-.. _alt-install:
+.. _inst-alt-install:
 
 Alternate Installation
 ======================
 you.
 
 
-.. _alt-install-prefix:
+.. _inst-alt-install-prefix:
 
 Alternate installation: the home scheme
 ---------------------------------------
    The :option:`--home` option used to be supported only on Unix.
 
 
-.. _alt-install-home:
+.. _inst-alt-install-home:
 
 Alternate installation: Unix (the prefix scheme)
 ------------------------------------------------
 alternate Python installation, this is immaterial.)
 
 
-.. _alt-install-windows:
+.. _inst-alt-install-windows:
 
 Alternate installation: Windows (the prefix scheme)
 ---------------------------------------------------
 +------------------------------+---------------------------+-----------------------------+
 
 
-.. _custom-install:
+.. _inst-custom-install:
 
 Custom Installation
 ===================
 
 Sometimes, the alternate installation schemes described in section
-:ref:`alt-install` just don't do what you want.  You might want to tweak just
+:ref:`inst-alt-install` just don't do what you want.  You might want to tweak just
 one or two directories while keeping everything under the same base directory,
 or you might want to completely redefine the installation scheme.  In either
 case, you're creating a *custom installation scheme*.
 The specified installation directories are relative to :file:`{prefix}`.  Of
 course, you also have to ensure that these directories are in Python's module
 search path, such as by putting a :file:`.pth` file in :file:`{prefix}`.  See
-section :ref:`search-path` to find out how to modify Python's search path.
+section :ref:`inst-search-path` to find out how to modify Python's search path.
 
 If you want to define an entire installation scheme, you just have to supply all
 of the installation directory options.  The recommended way to do this is to
 
 Obviously, specifying the entire installation scheme every time you install a
 new module distribution would be very tedious.  Thus, you can put these options
-into your Distutils config file (see section :ref:`config-files`)::
+into your Distutils config file (see section :ref:`inst-config-files`)::
 
    [install]
    install-base=$HOME
 the Distutils additionally define a few extra variables that may not be in your
 environment, such as ``$PLAT``.  (And of course, on systems that don't have
 environment variables, such as Mac OS 9, the configuration variables supplied by
-the Distutils are the only ones you can use.) See section :ref:`config-files`
+the Distutils are the only ones you can use.) See section :ref:`inst-config-files`
 for details.
 
 .. % XXX need some Windows examples---when would custom
 .. % XXX I'm not sure where this section should go.
 
 
-.. _search-path:
+.. _inst-search-path:
 
 Modifying Python's Search Path
 ------------------------------
 can modify it by adding or removing entries.
 
 
-.. _config-files:
+.. _inst-config-files:
 
 Distutils Configuration Files
 =============================
 by "later" files.
 
 
-.. _config-filenames:
+.. _inst-config-filenames:
 
 Location and names of config files
 ----------------------------------
    Distutils make no attempt to guess your home directory on Windows.)
 
 
-.. _config-syntax:
+.. _inst-config-syntax:
 
 Syntax of config files
 ----------------------
 See also the "Reference" section of the "Distributing Python Modules" manual.
 
 
-.. _building-ext:
+.. _inst-building-ext:
 
 Building Extensions: Tips and Tricks
 ====================================
 to override the usual Distutils behaviour.
 
 
-.. _tweak-flags:
+.. _inst-tweak-flags:
 
 Tweaking compiler/linker flags
 ------------------------------
 the compiler flags specified in the  :file:`Setup` file.
 
 
-.. _non-ms-compilers:
+.. _inst-non-ms-compilers:
 
 Using non-Microsoft compilers on Windows
 ----------------------------------------
 
 If you want to use the Borland C++ compiler as the default, you could specify
 this in your personal or system-wide configuration file for Distutils (see
-section :ref:`config-files`.)
+section :ref:`inst-config-files`.)
 
 
 .. seealso::
 
 If you want to use any of these options/compilers as default, you should
 consider to write it in your personal or system-wide configuration file for
-Distutils (see section :ref:`config-files`.)
+Distutils (see section :ref:`inst-config-files`.)
 
 
 .. seealso::

Doc-26/library/__builtin__.rst

 
 This module provides direct access to all 'built-in' identifiers of Python; for
 example, ``__builtin__.open`` is the full name for the built-in function
-:func:`open`.  See chapter :ref:`builtin`, "Built-in Objects."
+:func:`open`.  See chapter :ref:`builtin`.
 
 This module is not normally accessed explicitly by most applications, but can be
 useful in modules that provide objects with the same name as a built-in value,

Doc-26/library/csv.rst

    :func:`list_dialects` function.  The other optional *fmtparam* keyword arguments
    can be given to override individual formatting parameters in the current
    dialect.  For full details about the dialect and formatting parameters, see
-   section :ref:`csv-fmt-params`, "Dialects and Formatting Parameters".
+   section :ref:`csv-fmt-params`.
 
    All data read are returned as strings.  No automatic data type conversion is
    performed.
    :func:`list_dialects` function.  The other optional *fmtparam* keyword arguments
    can be given to override individual formatting parameters in the current
    dialect.  For full details about the dialect and formatting parameters, see
-   section :ref:`csv-fmt-params`, "Dialects and Formatting Parameters". To make it
+   section :ref:`csv-fmt-params`. To make it
    as easy as possible to interface with modules which implement the DB API, the
    value :const:`None` is written as the empty string.  While this isn't a
    reversible transformation, it makes it easier to dump SQL NULL data values to
    dialect can be specified either by passing a sub-class of :class:`Dialect`, or
    by *fmtparam* keyword arguments, or both, with keyword arguments overriding
    parameters of the dialect. For full details about the dialect and formatting
-   parameters, see section :ref:`csv-fmt-params`, "Dialects and Formatting
-   Parameters".
+   parameters, see section :ref:`csv-fmt-params`.
 
 
 .. function:: unregister_dialect(name)

Doc-26/library/ctypes.rst

 Arrays and pointers
 ^^^^^^^^^^^^^^^^^^^
 
-Not yet written - please see section :ref:`ctypes-pointers`, pointers and
-section :ref:`ctypes-arrays`, arrays in the tutorial.
-
+Not yet written - please see the sections :ref:`ctypes-pointers` and
+section :ref:`ctypes-arrays` in the tutorial.
+

Doc-26/library/datetime.rst

 
    Return a string representing the date, controlled by an explicit format string.
    Format codes referring to hours, minutes or seconds will see 0 values. See
-   section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   section :ref:`strftime-behavior`.
 
 
 .. _datetime-datetime:
 .. method:: datetime.strftime(format)
 
    Return a string representing the date and time, controlled by an explicit format
-   string.  See section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   string.  See section :ref:`strftime-behavior`.
 
 
 .. _datetime-time:
 .. method:: time.strftime(format)
 
    Return a string representing the time, controlled by an explicit format string.
-   See section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   See section :ref:`strftime-behavior`.
 
 
 .. method:: time.utcoffset()

Doc-26/library/functions.rst

 
 .. function:: file(filename[, mode[, bufsize]])
 
-   Constructor function for the :class:`file` type, described further  in section
-   :ref:`bltin-file-objects`, "File Objects (XXX reference: bltin-file-
-   objects.html)".  The constructor's arguments are the same as those of the
-   :func:`open` built-in function described below.
+   Constructor function for the :class:`file` type, described further in section
+   :ref:`bltin-file-objects`.  The constructor's arguments are the same as those
+   of the :func:`open` built-in function described below.
 
    When opening a file, it's preferable to use :func:`open` instead of  invoking
    this constructor directly.  :class:`file` is more suited to type testing (for
 
 .. function:: open(filename[, mode[, bufsize]])
 
-   Open a file, returning an object of the :class:`file` type described in section
-   :ref:`bltin-file-objects`, "File Objects (XXX reference: bltin-file-
-   objects.html)".  If the file cannot be opened, :exc:`IOError` is raised.  When
-   opening a file, it's preferable to use :func:`open` instead of invoking the
-   :class:`file` constructor directly.
+   Open a file, returning an object of the :class:`file` type described in
+   section :ref:`bltin-file-objects`.  If the file cannot be opened,
+   :exc:`IOError` is raised.  When opening a file, it's preferable to use
+   :func:`open` instead of invoking the :class:`file` constructor directly.
 
    The first two arguments are the same as for ``stdio``'s :cfunc:`fopen`:
    *filename* is the file name to be opened, and *mode* is a string indicating how

Doc-26/library/intro.rst

 function, module or term in the index (in the back).  And finally, if you enjoy
 learning about random subjects, you choose a random page number (see module
 :mod:`random`) and read a section or two.  Regardless of the order in which you
-read the sections of this manual, it helps to start  with chapter
-:ref:`builtin`, "Built-in Types, Exceptions and Functions," as the remainder of
-the manual assumes familiarity with this material.
+read the sections of this manual, it helps to start with chapter :ref:`builtin`,
+as the remainder of the manual assumes familiarity with this material.
 
 Let the show begin!
 

Doc-26/library/logging.rst

 of the :class:`LogRecord` attributes - such as the default value mentioned above
 making use of the fact that the user's message and arguments are pre-formatted
 into a :class:`LogRecord`'s *message* attribute.  This format string contains
-standard python %-style mapping keys. See section :ref:`typesseq-strings`,
-"String Formatting Operations," for more information on string formatting.
+standard python %-style mapping keys. See section :ref:`typesseq-strings`
+for more information on string formatting.
 
 Currently, the useful mapping keys in a :class:`LogRecord` are:
 

Doc-26/library/optparse.rst

 Actions tell :mod:`optparse` what to do when it encounters an option on the
 command line.  There is a fixed set of actions hard-coded into :mod:`optparse`;
 adding new actions is an advanced topic covered in section
-:ref:`optparse-extending-optparse`, Extending :mod:`optparse`. Most actions tell
+:ref:`optparse-extending-optparse`. Most actions tell
 :mod:`optparse` to store a value in some variable---for example, take a string
 from the command line and store it in an attribute of ``options``.
 
 default destination for ``"-f"`` is ``f``.
 
 :mod:`optparse` also includes built-in ``long`` and ``complex`` types.  Adding
-types is covered in section :ref:`optparse-extending-optparse`, Extending
-:mod:`optparse`.
+types is covered in section :ref:`optparse-extending-optparse`.
 
 
 .. _optparse-handling-boolean-options:
    call a specified function
 
 These are covered in section :ref:`optparse-reference-guide`, Reference Guide
-and section :ref:`optparse-option-callbacks`, Option Callbacks.
+and section :ref:`optparse-option-callbacks`.
 
 
 .. _optparse-default-values:
 
    ``conflict_handler`` (default: ``"error"``)
       Specifies what to do when options with conflicting option strings are added to
-      the parser; see section :ref:`optparse-conflicts-between-options`, Conflicts
-      between options.
+      the parser; see section :ref:`optparse-conflicts-between-options`.
 
    ``description`` (default: ``None``)
       A paragraph of text giving a brief overview of your program.  :mod:`optparse`
 
 There are several ways to populate the parser with options.  The preferred way
 is by using ``OptionParser.add_option()``, as shown in section
-:ref:`optparse-tutorial`, the tutorial.  :meth:`add_option` can be called in one
-of two ways:
+:ref:`optparse-tutorial`.  :meth:`add_option` can be called in one of two ways:
 
 * pass it an Option instance (as returned by :func:`make_option`)
 
 
      func(option, opt_str, value, parser, *args, **kwargs)
 
-  See section :ref:`optparse-option-callbacks`, Option Callbacks for more detail.
+  See section :ref:`optparse-option-callbacks` for more detail.
 
 * :attr:`help`
 
 
 * ``callback``
 
-  For options with action ``"callback"``, the callable to call when this option is
-  seen.  See section :ref:`optparse-option-callbacks`, Option Callbacks for detail
-  on the arguments passed to ``callable``.
+  For options with action ``"callback"``, the callable to call when this option
+  is seen.  See section :ref:`optparse-option-callbacks` for detail on the
+  arguments passed to ``callable``.
 
 * ``callback_args``, ``callback_kwargs``
 
 * ``metavar`` (default: derived from option strings)
 
   Stand-in for the option argument(s) to use when printing help text. See section
-  :ref:`optparse-tutorial`, the tutorial for an example.
+  :ref:`optparse-tutorial` for an example.
 
 
 .. _optparse-standard-option-types:
 
 :mod:`optparse` has six built-in option types: ``string``, ``int``, ``long``,
 ``choice``, ``float`` and ``complex``.  If you need to add new option types, see
-section :ref:`optparse-extending-optparse`, Extending :mod:`optparse`.
+section :ref:`optparse-extending-optparse`.
 
 Arguments to string options are not checked or converted in any way: the text on
 the command line is stored in the destination (or passed to the callback) as-is.

Doc-26/library/os.rst

               getcwd()
    :noindex:
 
-   These functions are described in "Files and Directories" (section
-   :ref:`os-file-dir`).
+   These functions are described in :ref:`os-file-dir`.
 
 
 .. function:: ctermid()
 available on Unix.
 
 For a discussion of possible deadlock conditions related to the use of these
-functions, see "Flow Control Issues (XXX reference: popen2-flow-control.html)"
-(section :ref:`popen2-flow-control`).
+functions, see :ref:`popen2-flow-control`.
 
 
 .. function:: popen2(cmd[, mode[, bufsize]])

Doc-26/library/pyexpat.rst

 .. exception:: ExpatError
 
    The exception raised when Expat reports an error.  See section
-   :ref:`expaterror-objects`, "ExpatError Exceptions," for more information on
-   interpreting Expat errors.
+   :ref:`expaterror-objects` for more information on interpreting Expat errors.
 
 
 .. exception:: error

Doc-26/library/shlex.rst

    was introduced in Python 2.3, and defines the operational mode.  When *posix* is
    not true (default), the :class:`shlex` instance will operate in compatibility
    mode.  When operating in POSIX mode, :class:`shlex` will try to be as close as
-   possible to the POSIX shell parsing rules.  See section :ref:`shlex-objects`.
+   possible to the POSIX shell parsing rules.
 
 
 .. seealso::

Doc-26/library/socket.rst

    .. index:: single: I/O control; buffering
 
    Return a :dfn:`file object` associated with the socket.  (File objects are
-   described in :ref:`bltin-file-objects`, "File Objects.") The file object
+   described in :ref:`bltin-file-objects`.) The file object
    references a :cfunc:`dup`\ ped version of the socket file descriptor, so the
    file object and socket object may be closed or garbage-collected independently.
    The socket must be in blocking mode (it can not have a timeout). The optional
    *mode* and *bufsize* arguments are interpreted the same way as by the built-in
-   :func:`file` function; see "Built-in Functions" (section :ref:`built-in-funcs`)
-   for more information.
+   :func:`file` function; see :ref:`built-in-funcs` for more information.
 
 
 .. method:: socket.recv(bufsize[, flags])

Doc-26/library/sqlite3.rst

 .. attribute:: Connection.isolation_level
 
    Get or set the current isolation level. None for autocommit mode or one of
-   "DEFERRED", "IMMEDIATE" or "EXLUSIVE". See "Controlling Transactions",  section
-   :ref:`sqlite3-controlling-transactions`, for a more detailed explanation.
+   "DEFERRED", "IMMEDIATE" or "EXLUSIVE". See section
+   :ref:`sqlite3-controlling-transactions` for a more detailed explanation.
 
 
 .. method:: Connection.cursor([cursorClass])
 
 * Explicitly via the column name
 
-Both ways are described in "Module Constants", section
-:ref:`sqlite3-module-contents`, in the entries for the constants
-:const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES`.
+Both ways are described in section :ref:`sqlite3-module-contents`, in the entries
+for the constants :const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES`.
 
 The following example illustrates both approaches.
 

Doc-26/library/stdtypes.rst

    for well-defined conversions.
 
 (3)
-   See section :ref:`built-in-funcs`, "Built-in Functions," for a full description.
+   See :ref:`built-in-funcs` for a full description.
 
 (4)
    Complex floor division operator, modulo operator, and :func:`divmod`.
 
 File objects are implemented using C's ``stdio`` package and can be created with
 the built-in constructor :func:`file` described in section
-:ref:`built-in-funcs`, "Built-in Functions." [#]_  File objects are also
-returned by some other built-in functions and methods, such as :func:`os.popen`
-and :func:`os.fdopen` and the :meth:`makefile` method of socket objects.
+:ref:`built-in-funcs`. [#]_ File objects are also returned by some other
+built-in functions and methods, such as :func:`os.popen` and :func:`os.fdopen`
+and the :meth:`makefile` method of socket objects.
 
 When a file operation fails for an I/O-related reason, the exception
 :exc:`IOError` is raised.  This includes situations where the operation is not
    might matter, for example, if you want to make an exact copy of a file while
    scanning its lines) to tell whether the last line of a file ended in a newline
    or not (yes this happens!).
-

Doc-26/library/string.rst

 ---------------------------
 
 The following list of functions are also defined as methods of string and
-Unicode objects; see "String Methods" (section :ref:`string-methods`) for more
-information on those.  You should consider these functions as deprecated,
-although they will not be removed until Python 3.0.  The functions defined in
-this module are:
+Unicode objects; see section :ref:`string-methods` for more information on
+those.  You should consider these functions as deprecated, although they will
+not be removed until Python 3.0.  The functions defined in this module are:
 
 
 .. function:: atof(s)

Doc-26/library/sys.rst

    Their intended use is to allow an interactive user to import a debugger module
    and engage in post-mortem debugging without having to re-execute the command
    that caused the error.  (Typical use is ``import pdb; pdb.pm()`` to enter the
-   post-mortem debugger; see chapter :ref:`debugger`, "The Python Debugger," for
+   post-mortem debugger; see chapter :ref:`debugger` for
    more information.)
 
    The meaning of the variables is the same as that of the return values from
       single: trace function
       single: debugger
 
-   Set the system's trace function, which allows you to implement a Python source
-   code debugger in Python.  See section :ref:`debugger-hooks`, "How It Works," in
-   the chapter on the Python debugger.  The function is thread-specific; for a
+   Set the system's trace function, which allows you to implement a Python
+   source code debugger in Python.  See section :ref:`debugger-hooks` in the
+   chapter on the Python debugger.  The function is thread-specific; for a
    debugger to support multiple threads, it must be registered using
    :func:`settrace` for each thread being debugged.
 

Doc-26/library/tarfile.rst

 
    Return a :class:`TarFile` object for the pathname *name*. For detailed
    information on :class:`TarFile` objects and the keyword arguments that are
-   allowed, see TarFile Objects (section :ref:`tarfile-objects`).
+   allowed, see :ref:`tarfile-objects`.
 
    *mode* has to be a string of the form ``'filemode[:compression]'``, it defaults
    to ``'r'``. Here is a full list of mode combinations:
 
    For special purposes, there is a second format for *mode*:
    ``'filemode|[compression]'``.  :func:`open` will return a :class:`TarFile`
-   object that processes its data as a stream of blocks.  No random seeking will be
-   done on the file. If given, *fileobj* may be any object that has a :meth:`read`
-   or :meth:`write` method (depending on the *mode*). *bufsize* specifies the
-   blocksize and defaults to ``20 * 512`` bytes. Use this variant in combination
-   with e.g. ``sys.stdin``, a socket file object or a tape device. However, such a
-   :class:`TarFile` object is limited in that it does not allow to be accessed
-   randomly, see "Examples" (section :ref:`tar-examples`).  The currently possible
-   modes:
+   object that processes its data as a stream of blocks.  No random seeking will
+   be done on the file. If given, *fileobj* may be any object that has a
+   :meth:`read` or :meth:`write` method (depending on the *mode*). *bufsize*
+   specifies the blocksize and defaults to ``20 * 512`` bytes. Use this variant
+   in combination with e.g. ``sys.stdin``, a socket file object or a tape
+   device. However, such a :class:`TarFile` object is limited in that it does
+   not allow to be accessed randomly, see :ref:`tar-examples`.  The currently
+   possible modes:
 
    +-------------+--------------------------------------------+
    | Mode        | Action                                     |
 .. class:: TarFile
 
    Class for reading and writing tar archives. Do not use this class directly,
-   better use :func:`open` instead. See "TarFile Objects" (section
-   :ref:`tarfile-objects`).
+   better use :func:`open` instead. See :ref:`tarfile-objects`.
 
 
 .. function:: is_tarfile(name)
 archive is a sequence of blocks. An archive member (a stored file) is made up of
 a header block followed by data blocks. It is possible to store a file in a tar
 archive several times. Each archive member is represented by a :class:`TarInfo`
-object, see TarInfo Objects (section :ref:`tarinfo-objects`) for details.
+object, see :ref:`tarinfo-objects` for details.
 
 
 .. class:: TarFile(name=None, mode='r', fileobj=None, format=DEFAULT_FORMAT, tarinfo=TarInfo, dereference=False, ignore_zeros=False, encoding=None, errors=None, pax_headers=None, debug=0, errorlevel=0)

Doc-26/library/tkinter.rst

 classes.  In addition, the internal module :mod:`_tkinter` provides a threadsafe
 mechanism which allows Python and Tcl to interact.
 
-Tk is not the only GUI for Python; see section :ref:`other-gui-packages`, "Other
-User Interface Modules and Packages," for more information on other GUI toolkits
-for Python.
+Tk is not the only GUI for Python; see section :ref:`other-gui-packages` for
+more information on other GUI toolkits for Python.
 
 .. % Other sections I have in mind are
 .. % Tkinter internals

Doc-26/library/urlparse.rst

    |                  |       | if present               |                      |
    +------------------+-------+--------------------------+----------------------+
 
-   See section :ref:`urlparse-result-object`, "Results of :func:`urlparse` and
-   :func:`urlsplit`," for more information on the result object.
+   See section :ref:`urlparse-result-object` for more information on the result
+   object.
 
    .. versionchanged:: 2.5
       Added attributes to return value.
    |                  |       | if present              |                      |
    +------------------+-------+-------------------------+----------------------+
 
-   See section :ref:`urlparse-result-object`, "Results of :func:`urlparse` and
-   :func:`urlsplit`," for more information on the result object.
+   See section :ref:`urlparse-result-object` for more information on the result
+   object.
 
    .. versionadded:: 2.2
 

Doc-26/library/userdict.rst

    hard to track down.
 
 In addition to supporting the methods and operations of string and Unicode
-objects (see section :ref:`string-methods`, "String Methods"),
-:class:`UserString` instances provide the following attribute:
+objects (see section :ref:`string-methods`), :class:`UserString` instances
+provide the following attribute:
 
 
 .. attribute:: MutableString.data

Doc-26/library/xml.dom.rst

 and OMG IDL.  The Python mapping defined here is based in large part on the IDL
 version of the specification, but strict compliance is not required (though
 implementations are free to support the strict mapping from IDL).  See section
-:ref:`dom-conformance`, "Conformance," for a detailed discussion of mapping
-requirements.
+:ref:`dom-conformance` for a detailed discussion of mapping requirements.
 
 
 .. seealso::
 strings.  It is fairly rare that you must do this, however, so this usage is not
 yet documented.
 
-+--------------------------------+---------------------------------+---------------------------------+
-| Interface                      | Section                         | Purpose                         |
-+================================+=================================+=================================+
-| :class:`DOMImplementation`     | :ref:`dom-implementation-       | Interface to the underlying     |
-|                                | objects`                        | implementation.                 |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Node`                  | :ref:`dom-node-objects`         | Base interface for most objects |
-|                                |                                 | in a document.                  |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`NodeList`              | :ref:`dom-nodelist-objects`     | Interface for a sequence of     |
-|                                |                                 | nodes.                          |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`DocumentType`          | :ref:`dom-documenttype-objects` | Information about the           |
-|                                |                                 | declarations needed to process  |
-|                                |                                 | a document.                     |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Document`              | :ref:`dom-document-objects`     | Object which represents an      |
-|                                |                                 | entire document.                |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Element`               | :ref:`dom-element-objects`      | Element nodes in the document   |
-|                                |                                 | hierarchy.                      |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Attr`                  | :ref:`dom-attr-objects`         | Attribute value nodes on        |
-|                                |                                 | element nodes.                  |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Comment`               | :ref:`dom-comment-objects`      | Representation of comments in   |
-|                                |                                 | the source document.            |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`Text`                  | :ref:`dom-text-objects`         | Nodes containing textual        |
-|                                |                                 | content from the document.      |
-+--------------------------------+---------------------------------+---------------------------------+
-| :class:`ProcessingInstruction` | :ref:`dom-pi-objects`           | Processing instruction          |
-|                                |                                 | representation.                 |
-+--------------------------------+---------------------------------+---------------------------------+
++--------------------------------+-----------------------------------+---------------------------------+
+| Interface                      | Section                           | Purpose                         |
++================================+===================================+=================================+
+| :class:`DOMImplementation`     | :ref:`dom-implementation-objects` | Interface to the underlying     |
+|                                |                                   | implementation.                 |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Node`                  | :ref:`dom-node-objects`           | Base interface for most objects |
+|                                |                                   | in a document.                  |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`NodeList`              | :ref:`dom-nodelist-objects`       | Interface for a sequence of     |
+|                                |                                   | nodes.                          |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`DocumentType`          | :ref:`dom-documenttype-objects`   | Information about the           |
+|                                |                                   | declarations needed to process  |
+|                                |                                   | a document.                     |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Document`              | :ref:`dom-document-objects`       | Object which represents an      |
+|                                |                                   | entire document.                |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Element`               | :ref:`dom-element-objects`        | Element nodes in the document   |
+|                                |                                   | hierarchy.                      |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Attr`                  | :ref:`dom-attr-objects`           | Attribute value nodes on        |
+|                                |                                   | element nodes.                  |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Comment`               | :ref:`dom-comment-objects`        | Representation of comments in   |
+|                                |                                   | the source document.            |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`Text`                  | :ref:`dom-text-objects`           | Nodes containing textual        |
+|                                |                                   | content from the document.      |
++--------------------------------+-----------------------------------+---------------------------------+
+| :class:`ProcessingInstruction` | :ref:`dom-pi-objects`             | Processing instruction          |
+|                                |                                   | representation.                 |
++--------------------------------+-----------------------------------+---------------------------------+
 
 An additional section describes the exceptions defined for working with the DOM
 in Python.

Doc-26/library/xml.sax.reader.rst

 
 .. class:: AttributesImpl(attrs)
 
-   This is an implementation of the :class:`Attributes` interface (XXX reference:
-   attributes-objects.html) (see section :ref:`attributes-objects`).  This is a
-   dictionary-like object which represents the element attributes in a
-   :meth:`startElement` call. In addition to the most useful dictionary operations,
-   it supports a number of other methods as described by the interface. Objects of
-   this class should be instantiated by readers; *attrs* must be a dictionary-like
-   object containing a mapping from attribute names to attribute values.
+   This is an implementation of the :class:`Attributes` interface (see section
+   :ref:`attributes-objects`).  This is a dictionary-like object which
+   represents the element attributes in a :meth:`startElement` call. In addition
+   to the most useful dictionary operations, it supports a number of other
+   methods as described by the interface. Objects of this class should be
+   instantiated by readers; *attrs* must be a dictionary-like object containing
+   a mapping from attribute names to attribute values.
 
 
 .. class:: AttributesNSImpl(attrs, qnames)
 
    Namespace-aware variant of :class:`AttributesImpl`, which will be passed to
    :meth:`startElementNS`. It is derived from :class:`AttributesImpl`, but
-   understands attribute names as two-tuples of *namespaceURI* and *localname*. In
-   addition, it provides a number of methods expecting qualified names as they
-   appear in the original document.  This class implements the
-   :class:`AttributesNS` interface (XXX reference: attributes-ns-objects.html) (see
-   section :ref:`attributes-ns-objects`).
+   understands attribute names as two-tuples of *namespaceURI* and
+   *localname*. In addition, it provides a number of methods expecting qualified
+   names as they appear in the original document.  This class implements the
+   :class:`AttributesNS` interface (see section :ref:`attributes-ns-objects`).
 
 
 .. _xmlreader-objects:
 The :class:`AttributesNS` Interface
 -----------------------------------
 
-This interface is a subtype of the :class:`Attributes` interface (XXX reference:
-attributes-objects.html) (see section :ref:`attributes-objects`).  All methods
-supported by that interface are also available on :class:`AttributesNS` objects.
+This interface is a subtype of the :class:`Attributes` interface (see section
+:ref:`attributes-objects`).  All methods supported by that interface are also
+available on :class:`AttributesNS` objects.
 
 The following methods are also available:
 

Doc-26/library/zipfile.rst

 
 .. class:: ZipFile
 
-   The class for reading and writing ZIP files.  See "ZipFile Objects" (section
-   :ref:`zipfile-objects`) for constructor details.
+   The class for reading and writing ZIP files.  See section
+   :ref:`zipfile-objects` for constructor details.
 
 
 .. class:: PyZipFile
 
 .. class:: ZipInfo([filename[, date_time]])
 
-   Class used to represent information about a member of an archive. Instances of
-   this class are returned by the :meth:`getinfo` and :meth:`infolist` methods of
-   :class:`ZipFile` objects.  Most users of the :mod:`zipfile` module will not need
-   to create these, but only use those created by this module. *filename* should be
-   the full name of the archive member, and *date_time* should be a tuple
-   containing six fields which describe the time of the last modification to the
-   file; the fields are described in section :ref:`zipinfo-objects`, "ZipInfo
-   Objects."
+   Class used to represent information about a member of an archive. Instances
+   of this class are returned by the :meth:`getinfo` and :meth:`infolist`
+   methods of :class:`ZipFile` objects.  Most users of the :mod:`zipfile` module
+   will not need to create these, but only use those created by this
+   module. *filename* should be the full name of the archive member, and
+   *date_time* should be a tuple containing six fields which describe the time
+   of the last modification to the file; the fields are described in section
+   :ref:`zipinfo-objects`.
 
 
 .. function:: is_zipfile(filename)

Doc-26/library/zipimport.rst

 
 .. class:: zipimporter
 
-   The class for importing ZIP files.  See "zipimporter Objects" (section
-   :ref:`zipimporter-objects`) for constructor details.
+   The class for importing ZIP files.  See section :ref:`zipimporter-objects`
+   for constructor details.
 
 
 .. seealso::

Doc-26/maclib/using.rst

 /.MacOSX/environment.plist`. See Apple's Technical Document QA1067 for details.
 
 For more information on installation Python packages in MacPython, see section
-:ref:`mac-package-manager`, "Installing Additional Python Packages."
+:ref:`mac-package-manager`.
 
 
 .. _ide:

Doc-26/reference/datamodel.rst

       the same dictionary entry.
 
       Dictionaries are mutable; they can be created by the ``{...}`` notation (see
-      section :ref:`dict`, "Dictionary Displays").
+      section :ref:`dict`).
 
       .. index::
          module: dbm
       pair: function; argument
 
    These are the types to which the function call operation (see section
-   :ref:`calls`, "Calls") can be applied:
+   :ref:`calls`) can be applied:
 
    User-defined functions
       .. index::
          object: function
          object: user-defined function
 
-      A user-defined function object is created by a function definition (see section
-      :ref:`function`, "Function definitions").  It should be called with an argument
-      list containing the same number of items as the function's formal parameter
+      A user-defined function object is created by a function definition (see
+      section :ref:`function`).  It should be called with an argument list
+      containing the same number of items as the function's formal parameter
       list.
 
       Special attributes:
          single: generator; iterator
 
       A function or method which uses the :keyword:`yield` statement (see section
-      :ref:`yield`, "The :keyword:`yield` statement") is called a :dfn:`generator
+      :ref:`yield`) is called a :dfn:`generator
       function`.  Such a function, when called, always returns an iterator object
       which can be used to execute the body of the function:  calling the iterator's
       :meth:`next` method will cause the function to execute until it provides a value
       object: module
 
    Modules are imported by the :keyword:`import` statement (see section
-   :ref:`import`, "The :keyword:`import` statement"). A module object has a
+   :ref:`import`). A module object has a
    namespace implemented by a dictionary object (this is the dictionary referenced
    by the func_globals attribute of functions defined in the module).  Attribute
    references are translated to lookups in this dictionary, e.g., ``m.x`` is
    of the shared library file.
 
 Classes
-   Class objects are created by class definitions (see section :ref:`class`, "Class
-   definitions"). A class has a namespace implemented by a dictionary object. Class
+   Class objects are created by class definitions (see section :ref:`class`).
+   A class has a namespace implemented by a dictionary object. Class
    attribute references are translated to lookups in this dictionary, e.g., ``C.x``
    is translated to ``C.__dict__["x"]``. When the attribute name is not found
    there, the attribute search continues in the base classes.  The search is depth-
       object: mapping
 
    Class instances can pretend to be numbers, sequences, or mappings if they have
-   methods with certain special names.  See section :ref:`specialnames`, "Special
-   method names."
+   methods with certain special names.  See section :ref:`specialnames`.
 
    .. index::
       single: __dict__ (instance attribute)
       unwinds the execution stack, at each unwound level a traceback object is
       inserted in front of the current traceback.  When an exception handler is
       entered, the stack trace is made available to the program. (See section
-      :ref:`try`, "The ``try`` statement.") It is accessible as ``sys.exc_traceback``,
+      :ref:`try`.) It is accessible as ``sys.exc_traceback``,
       and also as the third item of the tuple returned by ``sys.exc_info()``.  The
       latter is the preferred interface, since it works correctly when the program is
       using multiple threads. When the program contains no suitable handler, the stack

Doc-26/reference/expressions.rst

 the same box have the same precedence.  Unless the syntax is explicitly given,
 operators are binary.  Operators in the same box group left to right (except for
 comparisons, including tests, which all have the same precedence and chain from
-left to right --- see section :ref:`comparisons` -- and exponentiation, which
+left to right --- see section :ref:`comparisons` --- and exponentiation, which
 groups from right to left).
 
 +-----------------------------------------------+-------------------------------------+

Doc-26/reference/lexical_analysis.rst

    Not imported by ``from module import *``.  The special identifier ``_`` is used
    in the interactive interpreter to store the result of the last evaluation; it is
    stored in the :mod:`__builtin__` module.  When not in interactive mode, ``_``
-   has no special meaning and is not defined. See section :ref:`import`, "The
-   :keyword:`import` statement."
+   has no special meaning and is not defined. See section :ref:`import`.
 
    .. note::
 
    implementation (including the standard library); applications should not expect
    to define additional names using this convention.  The set of names of this
    class defined by Python may be extended in future versions. See section
-   :ref:`specialnames`, "Special method names."
+   :ref:`specialnames`.
 
 ``__*``
    Class-private names.  Names in this category, when used within the context of a
    class definition, are re-written to use a mangled form to help avoid name
    clashes between "private" attributes of base and derived classes. See section
-   :ref:`atom-identifiers`, "Identifiers (Names)."
+   :ref:`atom-identifiers`.
 
 
 .. _literals:

Doc-26/reference/simple_stmts.rst

 then executed (unless a syntax error occurs).  If it is an open file, the file
 is parsed until EOF and executed.  If it is a code object, it is simply
 executed.  In all cases, the code that's executed is expected to be valid as
-file input (see section :ref:`file-input`, "File input").  Be aware that the
+file input (see section :ref:`file-input`).  Be aware that the
 :keyword:`return` and :keyword:`yield` statements may not be used outside of
 function definitions even within the context of code passed to the
 :keyword:`exec` statement.

Doc-26/tutorial/errors.rst

 
 Many standard modules define their own exceptions to report errors that may
 occur in functions they define.  More information on classes is presented in
-chapter :ref:`tut-classes`, "Classes."
+chapter :ref:`tut-classes`.
 
 
 .. _tut-cleanup:

Doc-26/tutorial/modules.rst

 found there, the search continues in an installation-dependent default path; on
 Unix, this is usually :file:`.:/usr/local/lib/python`.
 
-Actually, modules are searched in the list of directories given by the  variable
-``sys.path`` which is initialized from the directory  containing the input
-script (or the current directory), :envvar:`PYTHONPATH` and the installation-
-dependent default.  This allows Python programs that know what they're doing to
-modify or replace the  module search path.  Note that because the directory
-containing the script being run is on the search path, it is important that the
-script not have the same name as a standard module, or Python will attempt to
-load the script as a module when that module is imported. This will generally be
-an error.  See section :ref:`tut-standardmodules`, "Standard Modules," for more
-information.
+Actually, modules are searched in the list of directories given by the variable
+``sys.path`` which is initialized from the directory containing the input script
+(or the current directory), :envvar:`PYTHONPATH` and the installation- dependent
+default.  This allows Python programs that know what they're doing to modify or
+replace the module search path.  Note that because the directory containing the
+script being run is on the search path, it is important that the script not have
+the same name as a standard module, or Python will attempt to load the script as
+a module when that module is imported. This will generally be an error.  See
+section :ref:`tut-standardmodules` for more information.
 
 
 "Compiled" Python files

Doc-3k/c-api/concrete.rst

 
 .. index:: single: PyBufferProcs
 
-More information on the buffer interface is provided in the section "Buffer
-Object Structures" (section :ref:`buffer-structs`), under the description for
-:ctype:`PyBufferProcs`.
+More information on the buffer interface is provided in the section 
+:ref:`buffer-structs`, under the description for :ctype:`PyBufferProcs`.
 
 A "buffer object" is defined in the :file:`bufferobject.h` header (included by
 :file:`Python.h`). These objects look very similar to string objects at the

Doc-3k/c-api/newtypes.rst

 .. cmember:: PyBufferProcs* PyTypeObject.tp_as_buffer
 
    Pointer to an additional structure that contains fields relevant only to objects
-   which implement the buffer interface.  These fields are documented in "Buffer
-   Object Structures" (section :ref:`buffer-structs`).
+   which implement the buffer interface.  These fields are documented in
+   :ref:`buffer-structs`.
 
    The :attr:`tp_as_buffer` field is not inherited, but the contained fields are
    inherited individually.

Doc-3k/extending/extending.rst

    }
 
 This function must be registered with the interpreter using the
-:const:`METH_VARARGS` flag; this is described in section :ref:`methodtable`,
-"The Module's Method Table and Initialization Function."  The
+:const:`METH_VARARGS` flag; this is described in section :ref:`methodtable`.  The
 :cfunc:`PyArg_ParseTuple` function and its arguments are documented in section
-:ref:`parsetuple`, "Extracting Parameters in Extension Functions."
+:ref:`parsetuple`.
 
 The macros :cfunc:`Py_XINCREF` and :cfunc:`Py_XDECREF` increment/decrement the
 reference count of an object and are safe in the presence of *NULL* pointers
 (but note that *temp* will not be  *NULL* in this context).  More info on them
-in section :ref:`refcounts`, "Reference Counts."
+in section :ref:`refcounts`.
 
 .. index:: single: PyEval_CallObject()
 

Doc-3k/install/index.rst

 .. % end{latexonly}
 
 
-.. _intro:
+.. _inst-intro:
 
 Introduction
 ============
 the Distributing Python Modules (XXX reference: ../dist/dist.html) manual.
 
 
-.. _trivial-install:
+.. _inst-trivial-install:
 
 Best case: trivial installation
 -------------------------------
 modules from standard source distributions.
 
 
-.. _new-standard:
+.. _inst-new-standard:
 
 The new standard: Distutils
 ---------------------------
 get out of this manual.
 
 
-.. _standard-install:
+.. _inst-standard-install:
 
 Standard Build and Install
 ==========================
 
-As described in section :ref:`new-standard`, building and installing a module
+As described in section :ref:`inst-new-standard`, building and installing a module
 distribution using the Distutils is usually one simple command::
 
    python setup.py install
 a :command:`Terminal` window to get a shell prompt.
 
 
-.. _platform-variations:
+.. _inst-platform-variations:
 
 Platform variations
 -------------------
    python setup.py install
 
 
-.. _splitting-up:
+.. _inst-splitting-up:
 
 Splitting the job up
 --------------------
 you'll run lots of individual Distutils commands on their own.
 
 
-.. _how-build-works:
+.. _inst-how-build-works:
 
 How building works
 ------------------
    python setup.py build --build-base=/tmp/pybuild/foo-1.0
 
 (Or you could do this permanently with a directive in your system or personal
-Distutils configuration file; see section :ref:`config-files`.)  Normally, this
+Distutils configuration file; see section :ref:`inst-config-files`.)  Normally, this
 isn't necessary.
 
 The default layout for the build tree is as follows::
 of installing Python modules and applications.
 
 
-.. _how-install-works:
+.. _inst-how-install-works:
 
 How installation works
 ----------------------
 
 If you don't want to install modules to the standard location, or if you don't
 have permission to write there, then you need to read about alternate
-installations in section :ref:`alt-install`.  If you want to customize your
-installation directories more heavily, see section :ref:`custom-install` on
+installations in section :ref:`inst-alt-install`.  If you want to customize your
+installation directories more heavily, see section :ref:`inst-custom-install` on
 custom installations.
 
 
-.. _alt-install:
+.. _inst-alt-install:
 
 Alternate Installation
 ======================
 you.
 
 
-.. _alt-install-prefix:
+.. _inst-alt-install-prefix:
 
 Alternate installation: the home scheme
 ---------------------------------------
    The :option:`--home` option used to be supported only on Unix.
 
 
-.. _alt-install-home:
+.. _inst-alt-install-home:
 
 Alternate installation: Unix (the prefix scheme)
 ------------------------------------------------
 alternate Python installation, this is immaterial.)
 
 
-.. _alt-install-windows:
+.. _inst-alt-install-windows:
 
 Alternate installation: Windows (the prefix scheme)
 ---------------------------------------------------
 +------------------------------+---------------------------+-----------------------------+
 
 
-.. _custom-install:
+.. _inst-custom-install:
 
 Custom Installation
 ===================
 
 Sometimes, the alternate installation schemes described in section
-:ref:`alt-install` just don't do what you want.  You might want to tweak just
+:ref:`inst-alt-install` just don't do what you want.  You might want to tweak just
 one or two directories while keeping everything under the same base directory,
 or you might want to completely redefine the installation scheme.  In either
 case, you're creating a *custom installation scheme*.
 The specified installation directories are relative to :file:`{prefix}`.  Of
 course, you also have to ensure that these directories are in Python's module
 search path, such as by putting a :file:`.pth` file in :file:`{prefix}`.  See
-section :ref:`search-path` to find out how to modify Python's search path.
+section :ref:`inst-search-path` to find out how to modify Python's search path.
 
 If you want to define an entire installation scheme, you just have to supply all
 of the installation directory options.  The recommended way to do this is to
 
 Obviously, specifying the entire installation scheme every time you install a
 new module distribution would be very tedious.  Thus, you can put these options
-into your Distutils config file (see section :ref:`config-files`)::
+into your Distutils config file (see section :ref:`inst-config-files`)::
 
    [install]
    install-base=$HOME
 the Distutils additionally define a few extra variables that may not be in your
 environment, such as ``$PLAT``.  (And of course, on systems that don't have
 environment variables, such as Mac OS 9, the configuration variables supplied by
-the Distutils are the only ones you can use.) See section :ref:`config-files`
+the Distutils are the only ones you can use.) See section :ref:`inst-config-files`
 for details.
 
 .. % XXX need some Windows examples---when would custom
 .. % XXX I'm not sure where this section should go.
 
 
-.. _search-path:
+.. _inst-search-path:
 
 Modifying Python's Search Path
 ------------------------------
 can modify it by adding or removing entries.
 
 
-.. _config-files:
+.. _inst-config-files:
 
 Distutils Configuration Files
 =============================
 by "later" files.
 
 
-.. _config-filenames:
+.. _inst-config-filenames:
 
 Location and names of config files
 ----------------------------------
    Distutils make no attempt to guess your home directory on Windows.)
 
 
-.. _config-syntax:
+.. _inst-config-syntax:
 
 Syntax of config files
 ----------------------
 See also the "Reference" section of the "Distributing Python Modules" manual.
 
 
-.. _building-ext:
+.. _inst-building-ext:
 
 Building Extensions: Tips and Tricks
 ====================================
 to override the usual Distutils behaviour.
 
 
-.. _tweak-flags:
+.. _inst-tweak-flags:
 
 Tweaking compiler/linker flags
 ------------------------------
 the compiler flags specified in the  :file:`Setup` file.
 
 
-.. _non-ms-compilers:
+.. _inst-non-ms-compilers:
 
 Using non-Microsoft compilers on Windows
 ----------------------------------------
 
 If you want to use the Borland C++ compiler as the default, you could specify
 this in your personal or system-wide configuration file for Distutils (see
-section :ref:`config-files`.)
+section :ref:`inst-config-files`.)
 
 
 .. seealso::
 
 If you want to use any of these options/compilers as default, you should
 consider to write it in your personal or system-wide configuration file for
-Distutils (see section :ref:`config-files`.)
+Distutils (see section :ref:`inst-config-files`.)
 
 
 .. seealso::

Doc-3k/library/__builtin__.rst

 
 This module provides direct access to all 'built-in' identifiers of Python; for
 example, ``__builtin__.open`` is the full name for the built-in function
-:func:`open`.  See chapter :ref:`builtin`, "Built-in Objects."
+:func:`open`.  See chapter :ref:`builtin`.
 
 This module is not normally accessed explicitly by most applications, but can be
 useful in modules that provide objects with the same name as a built-in value,

Doc-3k/library/csv.rst

    :func:`list_dialects` function.  The other optional *fmtparam* keyword arguments
    can be given to override individual formatting parameters in the current
    dialect.  For full details about the dialect and formatting parameters, see
-   section :ref:`csv-fmt-params`, "Dialects and Formatting Parameters".
+   section :ref:`csv-fmt-params`.
 
    All data read are returned as strings.  No automatic data type conversion is
    performed.
    :func:`list_dialects` function.  The other optional *fmtparam* keyword arguments
    can be given to override individual formatting parameters in the current
    dialect.  For full details about the dialect and formatting parameters, see
-   section :ref:`csv-fmt-params`, "Dialects and Formatting Parameters". To make it
+   section :ref:`csv-fmt-params`. To make it
    as easy as possible to interface with modules which implement the DB API, the
    value :const:`None` is written as the empty string.  While this isn't a
    reversible transformation, it makes it easier to dump SQL NULL data values to
    dialect can be specified either by passing a sub-class of :class:`Dialect`, or
    by *fmtparam* keyword arguments, or both, with keyword arguments overriding
    parameters of the dialect. For full details about the dialect and formatting
-   parameters, see section :ref:`csv-fmt-params`, "Dialects and Formatting
-   Parameters".
+   parameters, see section :ref:`csv-fmt-params`.
 
 
 .. function:: unregister_dialect(name)

Doc-3k/library/ctypes.rst

 Arrays and pointers
 ^^^^^^^^^^^^^^^^^^^
 
-Not yet written - please see section :ref:`ctypes-pointers`, pointers and
-section :ref:`ctypes-arrays`, arrays in the tutorial.
-
+Not yet written - please see the sections :ref:`ctypes-pointers` and
+section :ref:`ctypes-arrays` in the tutorial.
+

Doc-3k/library/datetime.rst

 
    Return a string representing the date, controlled by an explicit format string.
    Format codes referring to hours, minutes or seconds will see 0 values. See
-   section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   section :ref:`strftime-behavior`.
 
 
 .. _datetime-datetime:
 .. method:: datetime.strftime(format)
 
    Return a string representing the date and time, controlled by an explicit format
-   string.  See section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   string.  See section :ref:`strftime-behavior`.
 
 
 .. _datetime-time:
 .. method:: time.strftime(format)
 
    Return a string representing the time, controlled by an explicit format string.
-   See section :ref:`strftime-behavior` -- :meth:`strftime` behavior.
+   See section :ref:`strftime-behavior`.
 
 
 .. method:: time.utcoffset()

Doc-3k/library/functions.rst

 
 .. function:: file(filename[, mode[, bufsize]])
 
-   Constructor function for the :class:`file` type, described further  in section
-   :ref:`bltin-file-objects`, "File Objects (XXX reference: bltin-file-
-   objects.html)".  The constructor's arguments are the same as those of the
-   :func:`open` built-in function described below.
+   Constructor function for the :class:`file` type, described further in section
+   :ref:`bltin-file-objects`.  The constructor's arguments are the same as those
+   of the :func:`open` built-in function described below.
 
    When opening a file, it's preferable to use :func:`open` instead of  invoking
    this constructor directly.  :class:`file` is more suited to type testing (for
 
 .. function:: open(filename[, mode[, bufsize]])
 
-   Open a file, returning an object of the :class:`file` type described in section
-   :ref:`bltin-file-objects`, "File Objects (XXX reference: bltin-file-
-   objects.html)".  If the file cannot be opened, :exc:`IOError` is raised.  When
-   opening a file, it's preferable to use :func:`open` instead of invoking the
-   :class:`file` constructor directly.
+   Open a file, returning an object of the :class:`file` type described in
+   section :ref:`bltin-file-objects`.  If the file cannot be opened,
+   :exc:`IOError` is raised.  When opening a file, it's preferable to use
+   :func:`open` instead of invoking the :class:`file` constructor directly.
 
    The first two arguments are the same as for ``stdio``'s :cfunc:`fopen`:
    *filename* is the file name to be opened, and *mode* is a string indicating how

Doc-3k/library/intro.rst

 function, module or term in the index (in the back).  And finally, if you enjoy
 learning about random subjects, you choose a random page number (see module
 :mod:`random`) and read a section or two.  Regardless of the order in which you
-read the sections of this manual, it helps to start  with chapter
-:ref:`builtin`, "Built-in Types, Exceptions and Functions," as the remainder of
-the manual assumes familiarity with this material.
+read the sections of this manual, it helps to start with chapter :ref:`builtin`,
+as the remainder of the manual assumes familiarity with this material.
 
 Let the show begin!
 

Doc-3k/library/logging.rst

 of the :class:`LogRecord` attributes - such as the default value mentioned above
 making use of the fact that the user's message and arguments are pre-formatted
 into a :class:`LogRecord`'s *message* attribute.  This format string contains
-standard python %-style mapping keys. See section :ref:`typesseq-strings`,
-"String Formatting Operations," for more information on string formatting.
+standard python %-style mapping keys. See section :ref:`typesseq-strings`
+for more information on string formatting.
 
 Currently, the useful mapping keys in a :class:`LogRecord` are:
 

Doc-3k/library/optparse.rst

 Actions tell :mod:`optparse` what to do when it encounters an option on the
 command line.  There is a fixed set of actions hard-coded into :mod:`optparse`;
 adding new actions is an advanced topic covered in section
-:ref:`optparse-extending-optparse`, Extending :mod:`optparse`. Most actions tell
+:ref:`optparse-extending-optparse`. Most actions tell
 :mod:`optparse` to store a value in some variable---for example, take a string
 from the command line and store it in an attribute of ``options``.
 
 default destination for ``"-f"`` is ``f``.
 
 :mod:`optparse` also includes built-in ``long`` and ``complex`` types.  Adding
-types is covered in section :ref:`optparse-extending-optparse`, Extending
-:mod:`optparse`.
+types is covered in section :ref:`optparse-extending-optparse`.
 
 
 .. _optparse-handling-boolean-options:
    call a specified function
 
 These are covered in section :ref:`optparse-reference-guide`, Reference Guide
-and section :ref:`optparse-option-callbacks`, Option Callbacks.
+and section :ref:`optparse-option-callbacks`.
 
 
 .. _optparse-default-values:
 
    ``conflict_handler`` (default: ``"error"``)
       Specifies what to do when options with conflicting option strings are added to
-      the parser; see section :ref:`optparse-conflicts-between-options`, Conflicts
-      between options.
+      the parser; see section :ref:`optparse-conflicts-between-options`.
 
    ``description`` (default: ``None``)
       A paragraph of text giving a brief overview of your program.  :mod:`optparse`
 
 There are several ways to populate the parser with options.  The preferred way
 is by using ``OptionParser.add_option()``, as shown in section
-:ref:`optparse-tutorial`, the tutorial.  :meth:`add_option` can be called in one
-of two ways:
+:ref:`optparse-tutorial`.  :meth:`add_option` can be called in one of two ways:
 
 * pass it an Option instance (as returned by :func:`make_option`)
 
 
      func(option, opt_str, value, parser, *args, **kwargs)
 
-  See section :ref:`optparse-option-callbacks`, Option Callbacks for more detail.
+  See section :ref:`optparse-option-callbacks` for more detail.
 
 * :attr:`help`
 
 
 * ``callback``
 
-  For options with action ``"callback"``, the callable to call when this option is
-  seen.  See section :ref:`optparse-option-callbacks`, Option Callbacks for detail
-  on the arguments passed to ``callable``.
+  For options with action ``"callback"``, the callable to call when this option
+  is seen.  See section :ref:`optparse-option-callbacks` for detail on the
+  arguments passed to ``callable``.
 
 * ``callback_args``, ``callback_kwargs``
 
 * ``metavar`` (default: derived from option strings)
 
   Stand-in for the option argument(s) to use when printing help text. See section
-  :ref:`optparse-tutorial`, the tutorial for an example.
+  :ref:`optparse-tutorial` for an example.
 
 
 .. _optparse-standard-option-types:
 
 :mod:`optparse` has six built-in option types: ``string``, ``int``, ``long``,
 ``choice``, ``float`` and ``complex``.  If you need to add new option types, see
-section :ref:`optparse-extending-optparse`, Extending :mod:`optparse`.
+section :ref:`optparse-extending-optparse`.
 
 Arguments to string options are not checked or converted in any way: the text on
 the command line is stored in the destination (or passed to the callback) as-is.

Doc-3k/library/os.rst

               getcwd()
    :noindex:
 
-   These functions are described in "Files and Directories" (section
-   :ref:`os-file-dir`).
+   These functions are described in :ref:`os-file-dir`.
 
 
 .. function:: ctermid()

Doc-3k/library/pyexpat.rst

 .. exception:: ExpatError
 
    The exception raised when Expat reports an error.  See section
-   :ref:`expaterror-objects`, "ExpatError Exceptions," for more information on
-   interpreting Expat errors.
+   :ref:`expaterror-objects` for more information on interpreting Expat errors.
 
 
 .. exception:: error

Doc-3k/library/shlex.rst

    was introduced in Python 2.3, and defines the operational mode.  When *posix* is
    not true (default), the :class:`shlex` instance will operate in compatibility
    mode.  When operating in POSIX mode, :class:`shlex` will try to be as close as
-   possible to the POSIX shell parsing rules.  See section :ref:`shlex-objects`.
+   possible to the POSIX shell parsing rules.
 
 
 .. seealso::

Doc-3k/library/socket.rst

    .. index:: single: I/O control; buffering
 
    Return a :dfn:`file object` associated with the socket.  (File objects are
-   described in :ref:`bltin-file-objects`, "File Objects.") The file object
+   described in :ref:`bltin-file-objects`.) The file object
    references a :cfunc:`dup`\ ped version of the socket file descriptor, so the
    file object and socket object may be closed or garbage-collected independently.
    The socket must be in blocking mode (it can not have a timeout). The optional
    *mode* and *bufsize* arguments are interpreted the same way as by the built-in
-   :func:`file` function; see "Built-in Functions" (section :ref:`built-in-funcs`)
-   for more information.
+   :func:`file` function; see :ref:`built-in-funcs` for more information.
 
 
 .. method:: socket.recv(bufsize[, flags])

Doc-3k/library/sqlite3.rst

 .. attribute:: Connection.isolation_level
 
    Get or set the current isolation level. None for autocommit mode or one of
-   "DEFERRED", "IMMEDIATE" or "EXLUSIVE". See "Controlling Transactions",  section
-   :ref:`sqlite3-controlling-transactions`, for a more detailed explanation.
+   "DEFERRED", "IMMEDIATE" or "EXLUSIVE". See section
+   :ref:`sqlite3-controlling-transactions` for a more detailed explanation.
 
 
 .. method:: Connection.cursor([cursorClass])
 
 * Explicitly via the column name
 
-Both ways are described in "Module Constants", section
-:ref:`sqlite3-module-contents`, in the entries for the constants
-:const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES`.
+Both ways are described in section :ref:`sqlite3-module-contents`, in the entries
+for the constants :const:`PARSE_DECLTYPES` and :const:`PARSE_COLNAMES`.
 
 The following example illustrates both approaches.
 

Doc-3k/library/stdtypes.rst

    for well-defined conversions.
 
 (3)
-   See section :ref:`built-in-funcs`, "Built-in Functions," for a full description.
+   See :ref:`built-in-funcs` for a full description.
 
 (4)
    Complex floor division operator, modulo operator, and :func:`divmod`.
 
 File objects are implemented using C's ``stdio`` package and can be created with
 the built-in constructor :func:`file` described in section
-:ref:`built-in-funcs`, "Built-in Functions." [#]_  File objects are also
-returned by some other built-in functions and methods, such as :func:`os.popen`
-and :func:`os.fdopen` and the :meth:`makefile` method of socket objects.
+:ref:`built-in-funcs`. [#]_ File objects are also returned by some other
+built-in functions and methods, such as :func:`os.popen` and :func:`os.fdopen`
+and the :meth:`makefile` method of socket objects.
 
 When a file operation fails for an I/O-related reason, the exception
 :exc:`IOError` is raised.  This includes situations where the operation is not
    might matter, for example, if you want to make an exact copy of a file while
    scanning its lines) to tell whether the last line of a file ended in a newline
    or not (yes this happens!).
-

Doc-3k/library/string.rst

 ---------------------------
 
 The following list of functions are also defined as methods of string and
-Unicode objects; see "String Methods" (section :ref:`string-methods`) for more
-information on those.  You should consider these functions as deprecated,
-although they will not be removed until Python 3.0.  The functions defined in
-this module are:
+Unicode objects; see section :ref:`string-methods` for more information on
+those.  You should consider these functions as deprecated, although they will
+not be removed until Python 3.0.  The functions defined in this module are:
 
 
 .. function:: atof(s)

Doc-3k/library/sys.rst

    Their intended use is to allow an interactive user to import a debugger module
    and engage in post-mortem debugging without having to re-execute the command
    that caused the error.  (Typical use is ``import pdb; pdb.pm()`` to enter the
-   post-mortem debugger; see chapter :ref:`debugger`, "The Python Debugger," for
+   post-mortem debugger; see chapter :ref:`debugger` for
    more information.)
 
    The meaning of the variables is the same as that of the return values from
       single: trace function
       single: debugger
 
-   Set the system's trace function, which allows you to implement a Python source
-   code debugger in Python.  See section :ref:`debugger-hooks`, "How It Works," in
-   the chapter on the Python debugger.  The function is thread-specific; for a
+   Set the system's trace function, which allows you to implement a Python
+   source code debugger in Python.  See section :ref:`debugger-hooks` in the
+   chapter on the Python debugger.  The function is thread-specific; for a
    debugger to support multiple threads, it must be registered using
    :func:`settrace` for each thread being debugged.
 

Doc-3k/library/tarfile.rst

 
    Return a :class:`TarFile` object for the pathname *name*. For detailed
    information on :class:`TarFile` objects and the keyword arguments that are
-   allowed, see TarFile Objects (section :ref:`tarfile-objects`).
+   allowed, see :ref:`tarfile-objects`.
 
    *mode* has to be a string of the form ``'filemode[:compression]'``, it defaults
    to ``'r'``. Here is a full list of mode combinations:
 
    For special purposes, there is a second format for *mode*:
    ``'filemode|[compression]'``.  :func:`open` will return a :class:`TarFile`
-   object that processes its data as a stream of blocks.  No random seeking will be
-   done on the file. If given, *fileobj* may be any object that has a :meth:`read`
-   or :meth:`write` method (depending on the *mode*). *bufsize* specifies the
-   blocksize and defaults to ``20 * 512`` bytes. Use this variant in combination
-   with e.g. ``sys.stdin``, a socket file object or a tape device. However, such a
-   :class:`TarFile` object is limited in that it does not allow to be accessed
-   randomly, see "Examples" (section :ref:`tar-examples`).  The currently possible
-   modes:
+   object that processes its data as a stream of blocks.  No random seeking will
+   be done on the file. If given, *fileobj* may be any object that has a
+   :meth:`read` or :meth:`write` method (depending on the *mode*). *bufsize*
+   specifies the blocksize and defaults to ``20 * 512`` bytes. Use this variant
+   in combination with e.g. ``sys.stdin``, a socket file object or a tape
+   device. However, such a :class:`TarFile` object is limited in that it does
+   not allow to be accessed randomly, see :ref:`tar-examples`.  The currently
+   possible modes:
 
    +-------------+--------------------------------------------+
    | Mode        | Action                                     |
 .. class:: TarFile
 
    Class for reading and writing tar archives. Do not use this class directly,
-   better use :func:`open` instead. See "TarFile Objects" (section
-   :ref:`tarfile-objects`).
+   better use :func:`open` instead. See :ref:`tarfile-objects`.
 
 
 .. function:: is_tarfile(name)
 archive is a sequence of blocks. An archive member (a stored file) is made up of
 a header block followed by data blocks. It is possible to store a file in a tar
 archive several times. Each archive member is represented by a :class:`TarInfo`
-object, see TarInfo Objects (section :ref:`tarinfo-objects`) for details.
+object, see :ref:`tarinfo-objects` for details.
 
 
 .. class:: TarFile(name=None, mode='r', fileobj=None, format=DEFAULT_FORMAT, tarinfo=TarInfo, dereference=False, ignore_zeros=False, encoding=None, errors=None, pax_headers=None, debug=0, errorlevel=0)

Doc-3k/library/tkinter.rst

 classes.  In addition, the internal module :mod:`_tkinter` provides a threadsafe
 mechanism which allows Python and Tcl to interact.
 
-Tk is not the only GUI for Python; see section :ref:`other-gui-packages`, "Other
-User Interface Modules and Packages," for more information on other GUI toolkits
-for Python.
+Tk is not the only GUI for Python; see section :ref:`other-gui-packages` for
+more information on other GUI toolkits for Python.
 
 .. % Other sections I have in mind are
 .. % Tkinter internals

Doc-3k/library/urlparse.rst

    |                  |       | if present               |                      |
    +------------------+-------+--------------------------+----------------------+
 
-   See section :ref:`urlparse-result-object`, "Results of :func:`urlparse` and
-   :func:`urlsplit`," for more information on the result object.
+   See section :ref:`urlparse-result-object` for more information on the result
+   object.
 
    .. versionchanged:: 2.5
       Added attributes to return value.
    |                  |       | if present              |                      |
    +------------------+-------+-------------------------+----------------------+
 
-   See section :ref:`urlparse-result-object`, "Results of :func:`urlparse` and
-   :func:`urlsplit`," for more information on the result object.
+   See section :ref:`urlparse-result-object` for more information on the result
+   object.
 
    .. versionadded:: 2.2