diff --git a/Doc/ext/embedding.tex b/Doc/ext/embedding.tex
index 453a939..a44b89c 100644
--- a/Doc/ext/embedding.tex
+++ b/Doc/ext/embedding.tex
@@ -272,14 +272,14 @@
 % (what to watch out for)
 
 
-\section{Embedding Python in \Cpp{}
+\section{Embedding Python in \Cpp
      \label{embeddingInCplusplus}}
 
 It is also possible to embed Python in a \Cpp{} program; precisely how this
 is done will depend on the details of the \Cpp{} system used; in general you
-will need to write the main program in \Cpp{}, and use the \Cpp{} compiler
+will need to write the main program in \Cpp, and use the \Cpp{} compiler
 to compile and link your program.  There is no need to recompile Python
-itself using \Cpp{}.
+itself using \Cpp.
 
 
 \section{Linking Requirements
diff --git a/Doc/ext/extending.tex b/Doc/ext/extending.tex
index 49a561c..22623e9 100644
--- a/Doc/ext/extending.tex
+++ b/Doc/ext/extending.tex
@@ -1,4 +1,4 @@
-\chapter{Extending Python with C or \Cpp{} \label{intro}}
+\chapter{Extending Python with C or \Cpp \label{intro}}
 
 
 It is quite easy to add new built-in modules to Python, if you know
@@ -499,14 +499,14 @@
 \constant{METH_VARARGS} flag; this is described in section
 \ref{methodTable}, ``The Module's Method Table and Initialization
 Function.''  The \cfunction{PyArg_ParseTuple()} function and its
-arguments are documented in section \ref{parseTuple}, ``Extracting
+arguments are documented in section~\ref{parseTuple}, ``Extracting
 Parameters in Extension Functions.''
 
 The macros \cfunction{Py_XINCREF()} and \cfunction{Py_XDECREF()}
 increment/decrement the reference count of an object and are safe in
 the presence of \NULL{} pointers (but note that \var{temp} will not be 
-\NULL{} in this context).  More info on them in section
-\ref{refcounts}, ``Reference Counts.''
+\NULL{} in this context).  More info on them in
+section~\ref{refcounts}, ``Reference Counts.''
 
 Later, when it is time to call the function, you call the C function
 \cfunction{PyEval_CallObject()}.  This function has two arguments, both
@@ -544,7 +544,7 @@
 even (especially!) if you are not interested in its value.
 
 Before you do this, however, it is important to check that the return
-value isn't \NULL{}.  If it is, the Python function terminated by
+value isn't \NULL.  If it is, the Python function terminated by
 raising an exception.  If the C code that called
 \cfunction{PyEval_CallObject()} is called from Python, it should now
 return an error indication to its Python caller, so the interpreter
@@ -652,7 +652,7 @@
 
 \item[\samp{z} (string or \code{None}) {[char *]}]
 Like \samp{s}, but the Python object may also be \code{None}, in which
-case the C pointer is set to \NULL{}.
+case the C pointer is set to \NULL.
 
 \item[\samp{z\#} (string or \code{None} or any read buffer compatible object) 
 {[char *, int]}]
@@ -680,7 +680,7 @@
 second a pointer to a pointer to a character buffer (\var{**buffer},
 the buffer used for storing the encoded data).
 
-The encoding name must map to a registered codec. If set to \NULL{},
+The encoding name must map to a registered codec. If set to \NULL,
 the default encoding is used.
 
 \cfunction{PyArg_ParseTuple()} will allocate a buffer of the needed
@@ -705,7 +705,7 @@
 storing the encoded data) and the third one a pointer to an integer
 (\var{*buffer_length}, the buffer length).
 
-The encoding name must map to a registered codec. If set to \NULL{},
+The encoding name must map to a registered codec. If set to \NULL,
 the default encoding is used.
 
 There are two modes of operation: 
@@ -766,7 +766,7 @@
 Store a Python object (without any conversion) in a C object pointer.
 The C program thus receives the actual object that was passed.  The
 object's reference count is not increased.  The pointer stored is not
-\NULL{}.
+\NULL.
 
 \item[\samp{O!} (object) {[\var{typeobject}, PyObject *]}]
 Store a Python object in a C object pointer.  This is similar to
@@ -945,7 +945,7 @@
 The \var{arg} and \var{format} parameters are identical to those of the
 \cfunction{PyArg_ParseTuple()} function.  The \var{kwdict} parameter
 is the dictionary of keywords received as the third parameter from the
-Python runtime.  The \var{kwlist} parameter is a \NULL{}-terminated
+Python runtime.  The \var{kwlist} parameter is a \NULL-terminated
 list of strings which identify the parameters; the names are matched
 with the type information from \var{format} from left to right.  On
 success, \cfunction{PyArg_ParseTupleAndKeywords()} returns true,
@@ -1055,11 +1055,11 @@
 
 \item[\samp{s} (string) {[char *]}]
 Convert a null-terminated C string to a Python object.  If the C
-string pointer is \NULL{}, \code{None} is used.
+string pointer is \NULL, \code{None} is used.
 
 \item[\samp{s\#} (string) {[char *, int]}]
 Convert a C string and its length to a Python object.  If the C string
-pointer is \NULL{}, the length is ignored and \code{None} is
+pointer is \NULL, the length is ignored and \code{None} is
 returned.
 
 \item[\samp{z} (string or \code{None}) {[char *]}]
@@ -1171,10 +1171,10 @@
 \section{Reference Counts
          \label{refcounts}}
 
-In languages like C or \Cpp{}, the programmer is responsible for
+In languages like C or \Cpp, the programmer is responsible for
 dynamic allocation and deallocation of memory on the heap.  In C,
 this is done using the functions \cfunction{malloc()} and
-\cfunction{free()}.  In \Cpp{}, the operators \keyword{new} and
+\cfunction{free()}.  In \Cpp, the operators \keyword{new} and
 \keyword{delete} are used with essentially the same meaning; they are
 actually implemented using \cfunction{malloc()} and
 \cfunction{free()}, so we'll restrict the following discussion to the
@@ -1423,7 +1423,7 @@
 references generally return \NULL{} only to indicate that an
 exception occurred.  The reason for not testing for \NULL{}
 arguments is that functions often pass the objects they receive on to
-other function --- if each function were to test for \NULL{},
+other function --- if each function were to test for \NULL,
 there would be a lot of redundant tests and the code would run more
 slowly.
 
@@ -1458,10 +1458,10 @@
 % description.
 
 
-\section{Writing Extensions in \Cpp{}
+\section{Writing Extensions in \Cpp
          \label{cplusplus}}
 
-It is possible to write extension modules in \Cpp{}.  Some restrictions
+It is possible to write extension modules in \Cpp.  Some restrictions
 apply.  If the main program (the Python interpreter) is compiled and
 linked by the C compiler, global or static objects with constructors
 cannot be used.  This is not a problem if the main program is linked
diff --git a/Doc/ext/unix.tex b/Doc/ext/unix.tex
index 7e6dfd2..396909e 100644
--- a/Doc/ext/unix.tex
+++ b/Doc/ext/unix.tex
@@ -13,7 +13,7 @@
 that reflects various system variables determined by configure when
 the Python interpreter was built, so people building module's don't
 have to resupply these settings.  This vastly simplifies the process
-of building extensions and custom interpreters on Unix systems.
+of building extensions and custom interpreters on \UNIX{} systems.
 
 The make file make file is distributed as the file
 \file{Misc/Makefile.pre.in} in the Python source distribution.  The
diff --git a/Doc/ext/windows.tex b/Doc/ext/windows.tex
index 2068bb9..d42263b 100644
--- a/Doc/ext/windows.tex
+++ b/Doc/ext/windows.tex
@@ -3,7 +3,7 @@
 
 
 This chapter briefly explains how to create a Windows extension module
-for Python using Microsoft Visual \Cpp{}, and follows with more
+for Python using Microsoft Visual \Cpp, and follows with more
 detailed background information on how it works.  The explanatory
 material is useful for both the Windows programmer learning to build
 Python extensions and the \UNIX{} programmer interested in producing
@@ -66,7 +66,7 @@
 loading of code.  Before you try to build a module that can be
 dynamically loaded, be aware of how your system works.
 
-In \UNIX{}, a shared object (\file{.so}) file contains code to be used by the
+In \UNIX, a shared object (\file{.so}) file contains code to be used by the
 program, and also the names of functions and data that it expects to
 find in the program.  When the file is joined to the program, all
 references to those functions and data in the file's code are changed
@@ -80,7 +80,7 @@
 DLL's lookup table, and the lookup table is modified at runtime to
 point to the functions and data.
 
-In \UNIX{}, there is only one type of library file (\file{.a}) which
+In \UNIX, there is only one type of library file (\file{.a}) which
 contains code from several object files (\file{.o}).  During the link
 step to create a shared object file (\file{.so}), the linker may find
 that it doesn't know where an identifier is defined.  The linker will
@@ -99,7 +99,7 @@
 future DLLs that depend on the symbols in the application or DLL.
 
 Suppose you are building two dynamic-load modules, B and C, which should
-share another block of code A.  On \UNIX{}, you would \emph{not} pass
+share another block of code A.  On \UNIX, you would \emph{not} pass
 \file{A.a} to the linker for \file{B.so} and \file{C.so}; that would
 cause it to be included twice, so that B and C would each have their
 own copy.  In Windows, building \file{A.dll} will also build
@@ -109,14 +109,14 @@
 
 In Windows, using an import library is sort of like using \samp{import
 spam}; it gives you access to spam's names, but does not create a
-separate copy.  On \UNIX{}, linking with a library is more like
+separate copy.  On \UNIX, linking with a library is more like
 \samp{from spam import *}; it does create a separate copy.
 
 
 \section{Using DLLs in Practice \label{win-dlls}}
 \sectionauthor{Chris Phoenix}{cphoenix@best.com}
 
-Windows Python is built in Microsoft Visual \Cpp{}; using other
+Windows Python is built in Microsoft Visual \Cpp; using other
 compilers may or may not work (though Borland seems to).  The rest of
 this section is MSV\Cpp{} specific.