Some cleanup in the docs.

4 files changed, 23 insertions, 45 deletions

diff --git a/Doc/extending/embedding.rst b/Doc/extending/embedding.rst
index b9a567c..95a30fe 100644
--- a/Doc/extending/embedding.rst
+++ b/Doc/extending/embedding.rst
@@ -155,11 +155,7 @@ then the result should be::
 
 Although the program is quite large for its functionality, most of the code is
 for data conversion between Python and C, and for error reporting.  The
-interesting part with respect to embedding Python starts with
-
-.. % $
-
-::
+interesting part with respect to embedding Python starts with ::
 
    Py_Initialize();
    pName = PyString_FromString(argv[1]);
@@ -239,15 +235,8 @@ With these extensions, the Python script can do things like ::
 In a real application, the methods will expose an API of the application to
 Python.
 
-.. % \section{For the future}
-.. % 
-.. % You don't happen to have a nice library to get textual
-.. % equivalents of numeric values do you :-) ?
-.. % Callbacks here ? (I may be using information from that section
-.. % ?!)
-.. % threads
-.. % code examples do not really behave well if errors happen
-.. % (what to watch out for)
+.. TODO: threads, code examples do not really behave well if errors happen
+   (what to watch out for)
 
 
 .. _embeddingincplusplus:
diff --git a/Doc/extending/extending.rst b/Doc/extending/extending.rst
index 21eeddf..ae9e493 100644
--- a/Doc/extending/extending.rst
+++ b/Doc/extending/extending.rst
@@ -307,7 +307,7 @@ function.
 The method table must be passed to the interpreter in the module's
 initialization function.  The initialization function must be named
 :cfunc:`initname`, where *name* is the name of the module, and should be the
-only non-\ :keyword:`static` item defined in the module file::
+only non-\ ``static`` item defined in the module file::
 
    PyMODINIT_FUNC
    initspam(void)
@@ -665,11 +665,7 @@ it returns false and raises an appropriate exception.
 .. index:: single: Philbrick, Geoff
 
 Here is an example module which uses keywords, based on an example by Geoff
-Philbrick (philbrick@hks.com):
-
-.. % 
-
-::
+Philbrick (philbrick@hks.com)::
 
    #include "Python.h"
 
@@ -765,8 +761,8 @@ Reference Counts
 
 In languages like C or C++, the programmer is responsible for dynamic allocation
 and deallocation of memory on the heap.  In C, this is done using the functions
-:cfunc:`malloc` and :cfunc:`free`.  In C++, the operators :keyword:`new` and
-:keyword:`delete` are used with essentially the same meaning and we'll restrict
+:cfunc:`malloc` and :cfunc:`free`.  In C++, the operators ``new`` and
+``delete`` are used with essentially the same meaning and we'll restrict
 the following discussion to the C case.
 
 Every block of memory allocated with :cfunc:`malloc` should eventually be
@@ -1039,11 +1035,10 @@ that it is always a tuple. [#]_
 
 It is a severe error to ever let a *NULL* pointer "escape" to the Python user.
 
-.. % Frank Stajano:
-.. % A pedagogically buggy example, along the lines of the previous listing,
-.. % would be helpful here -- showing in more concrete terms what sort of
-.. % actions could cause the problem. I can't very well imagine it from the
-.. % description.
+.. Frank Stajano:
+   A pedagogically buggy example, along the lines of the previous listing, would
+   be helpful here -- showing in more concrete terms what sort of actions could
+   cause the problem. I can't very well imagine it from the description.
 
 
 .. _cplusplus:
@@ -1079,7 +1074,7 @@ lists, this new collection type should have a set of C functions for direct
 manipulation from other extension modules.
 
 At first sight this seems easy: just write the functions (without declaring them
-:keyword:`static`, of course), provide an appropriate header file, and document
+``static``, of course), provide an appropriate header file, and document
 the C API. And in fact this would work if all extension modules were always
 linked statically with the Python interpreter. When modules are used as shared
 libraries, however, the symbols defined in one module may not be visible to
@@ -1092,7 +1087,7 @@ the module whose functions one wishes to call might not have been loaded yet!
 
 Portability therefore requires not to make any assumptions about symbol
 visibility. This means that all symbols in extension modules should be declared
-:keyword:`static`, except for the module's initialization function, in order to
+``static``, except for the module's initialization function, in order to
 avoid name clashes with other extension modules (as discussed in section
 :ref:`methodtable`). And it means that symbols that *should* be accessible from
 other extension modules must be exported in a different way.
@@ -1127,7 +1122,7 @@ reality (such as adding "spam" to every command). This function
 :cfunc:`PySpam_System` is also exported to other extension modules.
 
 The function :cfunc:`PySpam_System` is a plain C function, declared
-:keyword:`static` like everything else::
+``static`` like everything else::
 
    static int
    PySpam_System(const char *command)
@@ -1183,7 +1178,7 @@ function must take care of initializing the C API pointer array::
            PyModule_AddObject(m, "_C_API", c_api_object);
    }
 
-Note that ``PySpam_API`` is declared :keyword:`static`; otherwise the pointer
+Note that ``PySpam_API`` is declared ``static``; otherwise the pointer
 array would disappear when :func:`initspam` terminates!
 
 The bulk of the work is in the header file :file:`spammodule.h`, which looks
diff --git a/Doc/extending/newtypes.rst b/Doc/extending/newtypes.rst
index e4d4e32..f9f8d43 100644
--- a/Doc/extending/newtypes.rst
+++ b/Doc/extending/newtypes.rst
@@ -232,8 +232,6 @@ at a shell should produce a file :file:`noddy.so` in a subdirectory; move to
 that directory and fire up Python --- you should be able to ``import noddy`` and
 play around with Noddy objects.
 
-.. % $ <-- bow to font-lock  ;-(
-
 That wasn't so hard, was it?
 
 Of course, the current Noddy type is pretty uninteresting. It has no data and
@@ -1235,16 +1233,14 @@ class object, and get the doc string using its :attr:`__doc__` attribute.
 As with the :attr:`tp_methods` table, a sentinel entry with a :attr:`name` value
 of *NULL* is required.
 
-.. % XXX Descriptors need to be explained in more detail somewhere, but
-.. % not here.
-.. % 
-.. % Descriptor objects have two handler functions which correspond to
-.. % the \member{tp_getattro} and \member{tp_setattro} handlers.  The
-.. % \method{__get__()} handler is a function which is passed the
-.. % descriptor, instance, and type objects, and returns the value of the
-.. % attribute, or it returns \NULL{} and sets an exception.  The
-.. % \method{__set__()} handler is passed the descriptor, instance, type,
-.. % and new value;
+.. XXX Descriptors need to be explained in more detail somewhere, but not here.
+   
+   Descriptor objects have two handler functions which correspond to the
+   \member{tp_getattro} and \member{tp_setattro} handlers.  The
+   \method{__get__()} handler is a function which is passed the descriptor,
+   instance, and type objects, and returns the value of the attribute, or it
+   returns \NULL{} and sets an exception.  The \method{__set__()} handler is
+   passed the descriptor, instance, type, and new value;
 
 
 Type-specific Attribute Management
diff --git a/Doc/extending/windows.rst b/Doc/extending/windows.rst
index 7a66afe..a34ba2b 100644
--- a/Doc/extending/windows.rst
+++ b/Doc/extending/windows.rst
@@ -7,8 +7,6 @@
 Building C and C++ Extensions on Windows
 ****************************************
 
-.. % 
-
 This chapter briefly explains how to create a Windows extension module for
 Python using Microsoft Visual C++, and follows with more detailed background
 information on how it works.  The explanatory material is useful for both the