Commits

Fred Drake committed cd47644

Small updates and grammatical adjustments.

Remove comment about this manual being out of date from the abstract.

  • Participants
  • Parent commits 61edd3b
  • Branches legacy-trunk

Comments (0)

Files changed (1)

File Doc/ext/ext.tex

 the language its wide application range.
 
 For a detailed description of the whole Python/C API, see the separate
-\emph{Python/C API Reference Manual}.  \strong{Note:} While that
-manual is still in a state of flux, it is safe to say that it is much
-more up to date than the manual you're reading currently (which has
-been in need for an upgrade for some time now).
+\emph{Python/C API Reference Manual}.
 
 
 \end{abstract}
 \tableofcontents
 
 
-\chapter{Extending Python with C or \Cpp{} code}
+\chapter{Extending Python with C or \Cpp{} \label{intro}}
 
 
-%\section{Introduction}
-\label{intro}
-
 It is quite easy to add new built-in modules to Python, if you know
 how to program in C.  Such \dfn{extension modules} can do two things
 that can't be done directly in Python: they can implement new built-in
     long k, l;
     char *s;
     int size;
-\end{verbatim}
 
-\begin{verbatim}
     ok = PyArg_ParseTuple(args, ""); /* No arguments */
         /* Python call: f() */
 \end{verbatim}
                   1, 2, 3, 4, 5, 6)          (((1, 2), (3, 4)), (5, 6))
 \end{verbatim}
 
+
 \section{Reference Counts
          \label{refcounts}}
 
-%\subsection{Introduction}
-
 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
 and gives full owner responsibilities (i.e., the new owner must
 dispose of the reference properly, as well as the previous owner).
 
+
 \subsection{Ownership Rules
             \label{ownershipRules}}
 
 Python must be an owned reference --- ownership is tranferred from the
 function to its caller.
 
+
 \subsection{Thin Ice
             \label{thinIce}}
 
 }
 \end{verbatim}
 
+
 \subsection{NULL Pointers
             \label{nullPointers}}
 
 \end{verbatim}
 
 In the beginning of the module, right after the line
+
 \begin{verbatim}
 #include "Python.h"
 \end{verbatim}
+
 two more lines must be added:
+
 \begin{verbatim}
 #define SPAM_MODULE
 #include "spammodule.h"
 included in the exporting module, not a client module. Finally,
 the module's initialization function must take care of initializing
 the C API pointer array:
+
 \begin{verbatim}
 void
 initspam()
 \end{verbatim}
 
 This is the simplest form of a module definition line.  It defines a
-dule, \module{ExtensionClass}, which has a single source file,
+module, \module{ExtensionClass}, which has a single source file,
 \file{ExtensionClass.c}.
 
-Here is a slightly more complex example that uses an \strong{-I}
-option to specify an include directory:
+This slightly more complex example uses an \strong{-I} option to
+specify an include directory:
 
 \begin{verbatim}
+EC=/projects/ExtensionClass
 cPersistence cPersistence.c -I$(EC)
-\end{verbatim}
+\end{verbatim} % $ <-- bow to font lock
 
 This example also illustrates the format for variable references.
 
 # include file.
 EC=/projects/ExtensionClass
 cPersistence cPersistence.c -I$(EC)
-\end{verbatim}
+\end{verbatim} % $ <-- bow to font lock
 
 After the \file{Setup} file has been created, \file{Makefile.pre.in}
 is run with the \samp{boot} target to create a make file:
 \file{Setup} file is changed.  The make file automatically rebuilds
 itself if the \file{Setup} file changes.
 
-\section{Building Custom Interpreters}
+
+\section{Building Custom Interpreters \label{custom-interps}}
 
 The make file built by \file{Makefile.pre.in} can be run with the
 \samp{static} target to build an interpreter:
 \samp{*shared*} line is omitted from the Setup file when a custom
 interpreter is desired.
 
-\section{Module Definition Options}
+
+\section{Module Definition Options \label{module-defn-options}}
 
 Several compiler options are supported:
 
 in variable variables.
 
 Source files can include files with \file{.c}, \file{.C}, \file{.cc},
-and \file{.c++} extensions. 
+\file{.cpp}, \file{.cxx}, and \file{.c++} extensions. 
 
-Other input files include files with \file{.o} or \file{.a}
-extensions.
+Other input files include files with \file{.a}, \file{.o}, \file{.sl}, 
+and \file{.so} extensions.
 
 
-\section{Example}
+\section{Example \label{module-defn-example}}
 
 Here is a more complicated example from \file{Modules/Setup.in}:
 
 people who do not have a source distribution of Python.
 
 Do not distribute a make file.  People building your modules
-should use \file{Makefile.pre.in} to build their own make file.
+should use \file{Makefile.pre.in} to build their own make file.  A
+\file{README} file included in the package should provide simple
+instructions to perform the build.
 
 Work is being done to make building and installing Python extensions
 easier for all platforms; this work in likely to supplant the current
 Python extensions and the \UNIX{} programming interested in producing
 software which can be successfully built on both \UNIX{} and Windows.
 
+
 \section{A Cookbook Approach \label{win-cookbook}}
 
 \sectionauthor{Neil Schemenauer}{neil_schemenauer@transcanada.com}