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}.
-\chapter{Extending Python with C or \Cpp{} code}
+\chapter{Extending Python with C or \Cpp{} \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;
     ok = PyArg_ParseTuple(args, ""); /* No arguments */
         /* Python call: f() */
                   1, 2, 3, 4, 5, 6)          (((1, 2), (3, 4)), (5, 6))
 \section{Reference Counts
 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
 Python must be an owned reference --- ownership is tranferred from the
 function to its caller.
 \subsection{Thin Ice
 \subsection{NULL Pointers
 In the beginning of the module, right after the line
 #include "Python.h"
 two more lines must be added:
 #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:
 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,
-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:
 cPersistence cPersistence.c -I$(EC)
+\end{verbatim} % $ <-- bow to font lock
 This example also illustrates the format for variable references.
 # include file.
 cPersistence cPersistence.c -I$(EC)
+\end{verbatim} % $ <-- bow to font lock
 After the \file{Setup} file has been created, \file{}
 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{} 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}
+Other input files include files with \file{.a}, \file{.o}, \file{.sl}, 
+and \file{.so} extensions.
+\section{Example \label{module-defn-example}}
 Here is a more complicated example from \file{Modules/}:
 people who do not have a source distribution of Python.
 Do not distribute a make file.  People building your modules
-should use \file{} to build their own make file.
+should use \file{} 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}{}