diff --git a/Doc/library/ctypes.rst b/Doc/library/ctypes.rst
index d649d1d..8e920f8 100644
--- a/Doc/library/ctypes.rst
+++ b/Doc/library/ctypes.rst
@@ -1392,7 +1392,7 @@
 
 The *use_last_error* parameter, when set to True, enables the same
 mechanism for the Windows error code which is managed by the
-GetLastError() and SetLastError() Windows api functions;
+:func:`GetLastError` and :func:`SetLastError` Windows API functions;
 `ctypes.get_last_error()` and `ctypes.set_last_error(value)` are used
 to request and change the ctypes private copy of the windows error
 code.
diff --git a/Doc/library/optparse.rst b/Doc/library/optparse.rst
index 76805fe..311655d 100644
--- a/Doc/library/optparse.rst
+++ b/Doc/library/optparse.rst
@@ -602,7 +602,7 @@
 programmer errors and user errors.  Programmer errors are usually erroneous
 calls to ``parser.add_option()``, e.g. invalid option strings, unknown option
 attributes, missing option attributes, etc.  These are dealt with in the usual
-way: raise an exception (either ``optparse.OptionError`` or ``TypeError``) and
+way: raise an exception (either ``optparse.OptionError`` or :exc:`TypeError`) and
 let the program crash.
 
 Handling user errors is much more important, since they are guaranteed to happen
@@ -799,10 +799,10 @@
 The keyword arguments define attributes of the new Option object.  The most
 important option attribute is :attr:`action`, and it largely determines which
 other attributes are relevant or required.  If you pass irrelevant option
-attributes, or fail to pass required ones, :mod:`optparse` raises an OptionError
-exception explaining your mistake.
+attributes, or fail to pass required ones, :mod:`optparse` raises an 
+:exc:`OptionError` exception explaining your mistake.
 
-An options's *action* determines what :mod:`optparse` does when it encounters
+An option's *action* determines what :mod:`optparse` does when it encounters
 this option on the command-line.  The standard option actions hard-coded into
 :mod:`optparse` are:
 
@@ -1059,7 +1059,7 @@
 The following option attributes may be passed as keyword arguments to
 ``parser.add_option()``.  If you pass an option attribute that is not relevant
 to a particular option, or fail to pass a required option attribute,
-:mod:`optparse` raises OptionError.
+:mod:`optparse` raises :exc:`OptionError`.
 
 * :attr:`action` (default: ``"store"``)
 
@@ -1152,7 +1152,7 @@
 ``choice`` options are a subtype of ``string`` options.  The ``choices`` option
 attribute (a sequence of strings) defines the set of allowed option arguments.
 ``optparse.check_choice()`` compares user-supplied option arguments against this
-master list and raises OptionValueError if an invalid string is given.
+master list and raises :exc:`OptionValueError` if an invalid string is given.
 
 
 .. _optparse-parsing-arguments:
@@ -1225,10 +1225,10 @@
    (e.g., ``"-q"`` or ``"--verbose"``).
 
 ``remove_option(opt_str)``
-   If the OptionParser has an option corresponding to ``opt_str``, that option is
+   If the :class:`OptionParser` has an option corresponding to ``opt_str``, that option is
    removed.  If that option provided any other option strings, all of those option
    strings become invalid. If ``opt_str`` does not occur in any option belonging to
-   this OptionParser, raises ValueError.
+   this :class:`OptionParser`, raises :exc:`ValueError`.
 
 
 .. _optparse-conflicts-between-options:
@@ -1259,13 +1259,13 @@
 The available conflict handlers are:
 
    ``error`` (default)
-      assume option conflicts are a programming error and raise  OptionConflictError
+      assume option conflicts are a programming error and raise :exc:`OptionConflictError`
 
    ``resolve``
       resolve option conflicts intelligently (see below)
 
 
-As an example, let's define an OptionParser that resolves conflicts
+As an example, let's define an :class:`OptionParser` that resolves conflicts
 intelligently and add conflicting options to it::
 
    parser = OptionParser(conflict_handler="resolve")
@@ -1495,7 +1495,7 @@
 Raising errors in a callback
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The callback function should raise OptionValueError if there are any problems
+The callback function should raise :exc:`OptionValueError` if there are any problems
 with the option or its argument(s).  :mod:`optparse` catches this and terminates
 the program, printing the error message you supply to stderr.  Your message
 should be clear, concise, accurate, and mention the option at fault.  Otherwise,
@@ -1696,9 +1696,9 @@
 :meth:`OptionParser.parse_args`, or be passed to a callback as the ``value``
 parameter.
 
-Your type-checking function should raise OptionValueError if it encounters any
-problems.  OptionValueError takes a single string argument, which is passed
-as-is to OptionParser's :meth:`error` method, which in turn prepends the program
+Your type-checking function should raise :exc:`OptionValueError` if it encounters any
+problems.  :exc:`OptionValueError` takes a single string argument, which is passed
+as-is to :class:`OptionParser`'s :meth:`error` method, which in turn prepends the program
 name and the string ``"error:"`` and prints everything to stderr before
 terminating the process.
 
diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
index b147734..1e1f03e 100644
--- a/Doc/library/subprocess.rst
+++ b/Doc/library/subprocess.rst
@@ -138,7 +138,7 @@
 .. function:: check_call(*popenargs, **kwargs)
 
    Run command with arguments.  Wait for command to complete. If the exit code was
-   zero then return, otherwise raise :exc:`CalledProcessError.` The
+   zero then return, otherwise raise :exc:`CalledProcessError`. The
    :exc:`CalledProcessError` object will have the return code in the
    :attr:`returncode` attribute.