Some cleanup in the docs.
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 @@
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 @@
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 @@
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 @@
.. 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 @@
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 @@
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 @@
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 @@
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 @@
: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 @@
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 @@
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 @@
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