diff options
| -rw-r--r-- | Doc/extref.tex | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/Doc/extref.tex b/Doc/extref.tex index 60940f5..183abd0 100644 --- a/Doc/extref.tex +++ b/Doc/extref.tex @@ -2,6 +2,8 @@ \chapter{Extension Reference} +\section{Introduction} + From the viewpoint of of C access to Python services, we have: \begin{enumerate} @@ -13,7 +15,7 @@ From the viewpoint of of C access to Python services, we have: to write a simple application that gets Python code from the user, execs it, and returns the output or errors. - \item "Abstract objects layer": which is the subject of this proposal. + \item "Abstract objects layer": which is the subject of this chapter. It has many functions operating on objects, and lest you do many things from C that you can also write in Python, without going through the Python parser. @@ -46,6 +48,23 @@ From the viewpoint of of C access to Python services, we have: so new objects can be returned from C functions that otherwise treat objects generically. +\subsection{Memory Management} + + For all of the functions described in this chapter, if a function + retains a reference to a Python object passed as an argument, then the + function will increase the reference count of the object. It is + unnecessary for the caller to increase the reference count of an + argument in anticipation of the object's retention. + + All Python objects returned from functions should be treated as new + objects. Functions that return objects assume that the caller will + retain a reference and the reference count of the object has already + been incremented to account for this fact. A caller that does not + retain a reference to an object that is returned from a function + must decrement the reference count of the object (using + DECREF(object)) to prevent memory leaks. + + \section{Object Protocol} \begin{cfuncdesc}{int}{PyObject_Print}{PyObject *o, FILE *fp, int flags} |