diff options
author | Fred Drake <fdrake@acm.org> | 1998-05-06 21:51:05 (GMT) |
---|---|---|
committer | Fred Drake <fdrake@acm.org> | 1998-05-06 21:51:05 (GMT) |
commit | 2880beb3d90d5522b1be2a703c09b16366de6452 (patch) | |
tree | db5e91866ef24f6df1c42f1c6455bfced3c5d83f | |
parent | 56727e2b702a3aae68c0dd7ae556b935bbf78157 (diff) | |
download | cpython-2880beb3d90d5522b1be2a703c09b16366de6452.zip cpython-2880beb3d90d5522b1be2a703c09b16366de6452.tar.gz cpython-2880beb3d90d5522b1be2a703c09b16366de6452.tar.bz2 |
Relocating file to Doc/api.
-rw-r--r-- | Doc/api.tex | 3016 |
1 files changed, 0 insertions, 3016 deletions
diff --git a/Doc/api.tex b/Doc/api.tex deleted file mode 100644 index b0b7bfd..0000000 --- a/Doc/api.tex +++ /dev/null @@ -1,3016 +0,0 @@ -\documentclass{manual} - -\title{Python/C API Reference Manual} - -\input{boilerplate} - -\makeindex % tell \index to actually write the .idx file - - -\begin{document} - -\maketitle - -\input{copyright} - -\begin{abstract} - -\noindent -This manual documents the API used by \C{} (or \Cpp{}) programmers who -want to write extension modules or embed Python. It is a companion to -\emph{Extending and Embedding the Python Interpreter}, which describes -the general principles of extension writing but does not document the -API functions in detail. - -\strong{Warning:} The current version of this document is incomplete. -I hope that it is nevertheless useful. I will continue to work on it, -and release new versions from time to time, independent from Python -source code releases. - -\end{abstract} - -\tableofcontents - -% XXX Consider moving all this back to ext.tex and giving api.tex -% XXX a *really* short intro only. - -\chapter{Introduction} -\label{intro} - -The Application Programmer's Interface to Python gives \C{} and \Cpp{} -programmers access to the Python interpreter at a variety of levels. -The API is equally usable from \Cpp{}, but for brevity it is generally -referred to as the Python/\C{} API. There are two fundamentally -different reasons for using the Python/\C{} API. The first reason is -to write \emph{extension modules} for specific purposes; these are -\C{} modules that extend the Python interpreter. This is probably the -most common use. The second reason is to use Python as a component in -a larger application; this technique is generally referred to as -\dfn{embedding} Python in an application. - -Writing an extension module is a relatively well-understood process, -where a ``cookbook'' approach works well. There are several tools -that automate the process to some extent. While people have embedded -Python in other applications since its early existence, the process of -embedding Python is less straightforward that writing an extension. -Python 1.5 introduces a number of new API functions as well as some -changes to the build process that make embedding much simpler. -This manual describes the \version\ state of affairs. -% XXX Eventually, take the historical notes out - -Many API functions are useful independent of whether you're embedding -or extending Python; moreover, most applications that embed Python -will need to provide a custom extension as well, so it's probably a -good idea to become familiar with writing an extension before -attempting to embed Python in a real application. - -\section{Include Files} -\label{includes} - -All function, type and macro definitions needed to use the Python/C -API are included in your code by the following line: - -\begin{verbatim} -#include "Python.h" -\end{verbatim} - -This implies inclusion of the following standard headers: -\code{<stdio.h>}, \code{<string.h>}, \code{<errno.h>}, and -\code{<stdlib.h>} (if available). - -All user visible names defined by Python.h (except those defined by -the included standard headers) have one of the prefixes \samp{Py} or -\samp{_Py}. Names beginning with \samp{_Py} are for internal use -only. Structure member names do not have a reserved prefix. - -\strong{Important:} user code should never define names that begin -with \samp{Py} or \samp{_Py}. This confuses the reader, and -jeopardizes the portability of the user code to future Python -versions, which may define additional names beginning with one of -these prefixes. - -\section{Objects, Types and Reference Counts} -\label{objects} - -Most Python/C API functions have one or more arguments as well as a -return value of type \ctype{PyObject *}. This type is a pointer -to an opaque data type representing an arbitrary Python -object. Since all Python object types are treated the same way by the -Python language in most situations (e.g., assignments, scope rules, -and argument passing), it is only fitting that they should be -represented by a single \C{} type. All Python objects live on the heap: -you never declare an automatic or static variable of type -\ctype{PyObject}, only pointer variables of type \ctype{PyObject *} can -be declared. - -All Python objects (even Python integers) have a \dfn{type} and a -\dfn{reference count}. An object's type determines what kind of object -it is (e.g., an integer, a list, or a user-defined function; there are -many more as explained in the \emph{Python Reference Manual}). For -each of the well-known types there is a macro to check whether an -object is of that type; for instance, \samp{PyList_Check(\var{a})} is -true iff the object pointed to by \var{a} is a Python list. - -\subsection{Reference Counts} -\label{refcounts} - -The reference count is important because today's computers have a -finite (and often severely limited) memory size; it counts how many -different places there are that have a reference to an object. Such a -place could be another object, or a global (or static) \C{} variable, or -a local variable in some \C{} function. When an object's reference count -becomes zero, the object is deallocated. If it contains references to -other objects, their reference count is decremented. Those other -objects may be deallocated in turn, if this decrement makes their -reference count become zero, and so on. (There's an obvious problem -with objects that reference each other here; for now, the solution is -``don't do that''.) - -Reference counts are always manipulated explicitly. The normal way is -to use the macro \cfunction{Py_INCREF()} to increment an object's -reference count by one, and \cfunction{Py_DECREF()} to decrement it by -one. The decref macro is considerably more complex than the incref one, -since it must check whether the reference count becomes zero and then -cause the object's deallocator, which is a function pointer contained -in the object's type structure. The type-specific deallocator takes -care of decrementing the reference counts for other objects contained -in the object, and so on, if this is a compound object type such as a -list. There's no chance that the reference count can overflow; at -least as many bits are used to hold the reference count as there are -distinct memory locations in virtual memory (assuming -\code{sizeof(long) >= sizeof(char *)}). Thus, the reference count -increment is a simple operation. - -It is not necessary to increment an object's reference count for every -local variable that contains a pointer to an object. In theory, the -object's reference count goes up by one when the variable is made to -point to it and it goes down by one when the variable goes out of -scope. However, these two cancel each other out, so at the end the -reference count hasn't changed. The only real reason to use the -reference count is to prevent the object from being deallocated as -long as our variable is pointing to it. If we know that there is at -least one other reference to the object that lives at least as long as -our variable, there is no need to increment the reference count -temporarily. An important situation where this arises is in objects -that are passed as arguments to \C{} functions in an extension module -that are called from Python; the call mechanism guarantees to hold a -reference to every argument for the duration of the call. - -However, a common pitfall is to extract an object from a list and -hold on to it for a while without incrementing its reference count. -Some other operation might conceivably remove the object from the -list, decrementing its reference count and possible deallocating it. -The real danger is that innocent-looking operations may invoke -arbitrary Python code which could do this; there is a code path which -allows control to flow back to the user from a \cfunction{Py_DECREF()}, -so almost any operation is potentially dangerous. - -A safe approach is to always use the generic operations (functions -whose name begins with \samp{PyObject_}, \samp{PyNumber_}, -\samp{PySequence_} or \samp{PyMapping_}). These operations always -increment the reference count of the object they return. This leaves -the caller with the responsibility to call \cfunction{Py_DECREF()} -when they are done with the result; this soon becomes second nature. - -\subsubsection{Reference Count Details} -\label{refcountDetails} - -The reference count behavior of functions in the Python/C API is best -expelained in terms of \emph{ownership of references}. Note that we -talk of owning references, never of owning objects; objects are always -shared! When a function owns a reference, it has to dispose of it -properly --- either by passing ownership on (usually to its caller) or -by calling \cfunction{Py_DECREF()} or \cfunction{Py_XDECREF()}. When -a function passes ownership of a reference on to its caller, the -caller is said to receive a \emph{new} reference. When no ownership -is transferred, the caller is said to \emph{borrow} the reference. -Nothing needs to be done for a borrowed reference. - -Conversely, when calling a function passes it a reference to an -object, there are two possibilities: the function \emph{steals} a -reference to the object, or it does not. Few functions steal -references; the two notable exceptions are -\cfunction{PyList_SetItem()} and \cfunction{PyTuple_SetItem()}, which -steal a reference to the item (but not to the tuple or list into which -the item is put!). These functions were designed to steal a reference -because of a common idiom for populating a tuple or list with newly -created objects; for example, the code to create the tuple \code{(1, -2, "three")} could look like this (forgetting about error handling for -the moment; a better way to code this is shown below anyway): - -\begin{verbatim} -PyObject *t; - -t = PyTuple_New(3); -PyTuple_SetItem(t, 0, PyInt_FromLong(1L)); -PyTuple_SetItem(t, 1, PyInt_FromLong(2L)); -PyTuple_SetItem(t, 2, PyString_FromString("three")); -\end{verbatim} - -Incidentally, \cfunction{PyTuple_SetItem()} is the \emph{only} way to -set tuple items; \cfunction{PySequence_SetItem()} and -\cfunction{PyObject_SetItem()} refuse to do this since tuples are an -immutable data type. You should only use -\cfunction{PyTuple_SetItem()} for tuples that you are creating -yourself. - -Equivalent code for populating a list can be written using -\cfunction{PyList_New()} and \cfunction{PyList_SetItem()}. Such code -can also use \cfunction{PySequence_SetItem()}; this illustrates the -difference between the two (the extra \cfunction{Py_DECREF()} calls): - -\begin{verbatim} -PyObject *l, *x; - -l = PyList_New(3); -x = PyInt_FromLong(1L); -PySequence_SetItem(l, 0, x); Py_DECREF(x); -x = PyInt_FromLong(2L); -PySequence_SetItem(l, 1, x); Py_DECREF(x); -x = PyString_FromString("three"); -PySequence_SetItem(l, 2, x); Py_DECREF(x); -\end{verbatim} - -You might find it strange that the ``recommended'' approach takes more -code. However, in practice, you will rarely use these ways of -creating and populating a tuple or list. There's a generic function, -\cfunction{Py_BuildValue()}, that can create most common objects from -\C{} values, directed by a \dfn{format string}. For example, the -above two blocks of code could be replaced by the following (which -also takes care of the error checking): - -\begin{verbatim} -PyObject *t, *l; - -t = Py_BuildValue("(iis)", 1, 2, "three"); -l = Py_BuildValue("[iis]", 1, 2, "three"); -\end{verbatim} - -It is much more common to use \cfunction{PyObject_SetItem()} and -friends with items whose references you are only borrowing, like -arguments that were passed in to the function you are writing. In -that case, their behaviour regarding reference counts is much saner, -since you don't have to increment a reference count so you can give a -reference away (``have it be stolen''). For example, this function -sets all items of a list (actually, any mutable sequence) to a given -item: - -\begin{verbatim} -int set_all(PyObject *target, PyObject *item) -{ - int i, n; - - n = PyObject_Length(target); - if (n < 0) - return -1; - for (i = 0; i < n; i++) { - if (PyObject_SetItem(target, i, item) < 0) - return -1; - } - return 0; -} -\end{verbatim} - -The situation is slightly different for function return values. -While passing a reference to most functions does not change your -ownership responsibilities for that reference, many functions that -return a referece to an object give you ownership of the reference. -The reason is simple: in many cases, the returned object is created -on the fly, and the reference you get is the only reference to the -object. Therefore, the generic functions that return object -references, like \cfunction{PyObject_GetItem()} and -\cfunction{PySequence_GetItem()}, always return a new reference (i.e., -the caller becomes the owner of the reference). - -It is important to realize that whether you own a reference returned -by a function depends on which function you call only --- \emph{the -plumage} (i.e., the type of the type of the object passed as an -argument to the function) \emph{doesn't enter into it!} Thus, if you -extract an item from a list using \cfunction{PyList_GetItem()}, you -don't own the reference --- but if you obtain the same item from the -same list using \cfunction{PySequence_GetItem()} (which happens to -take exactly the same arguments), you do own a reference to the -returned object. - -Here is an example of how you could write a function that computes the -sum of the items in a list of integers; once using -\cfunction{PyList_GetItem()}, once using -\cfunction{PySequence_GetItem()}. - -\begin{verbatim} -long sum_list(PyObject *list) -{ - int i, n; - long total = 0; - PyObject *item; - - n = PyList_Size(list); - if (n < 0) - return -1; /* Not a list */ - for (i = 0; i < n; i++) { - item = PyList_GetItem(list, i); /* Can't fail */ - if (!PyInt_Check(item)) continue; /* Skip non-integers */ - total += PyInt_AsLong(item); - } - return total; -} -\end{verbatim} - -\begin{verbatim} -long sum_sequence(PyObject *sequence) -{ - int i, n; - long total = 0; - PyObject *item; - n = PyObject_Size(list); - if (n < 0) - return -1; /* Has no length */ - for (i = 0; i < n; i++) { - item = PySequence_GetItem(list, i); - if (item == NULL) - return -1; /* Not a sequence, or other failure */ - if (PyInt_Check(item)) - total += PyInt_AsLong(item); - Py_DECREF(item); /* Discard reference ownership */ - } - return total; -} -\end{verbatim} - -\subsection{Types} -\label{types} - -There are few other data types that play a significant role in -the Python/C API; most are simple \C{} types such as \ctype{int}, -\ctype{long}, \ctype{double} and \ctype{char *}. A few structure types -are used to describe static tables used to list the functions exported -by a module or the data attributes of a new object type. These will -be discussed together with the functions that use them. - -\section{Exceptions} -\label{exceptions} - -The Python programmer only needs to deal with exceptions if specific -error handling is required; unhandled exceptions are automatically -propagated to the caller, then to the caller's caller, and so on, till -they reach the top-level interpreter, where they are reported to the -user accompanied by a stack traceback. - -For \C{} programmers, however, error checking always has to be explicit. -All functions in the Python/C API can raise exceptions, unless an -explicit claim is made otherwise in a function's documentation. In -general, when a function encounters an error, it sets an exception, -discards any object references that it owns, and returns an -error indicator --- usually \NULL{} or \code{-1}. A few functions -return a Boolean true/false result, with false indicating an error. -Very few functions return no explicit error indicator or have an -ambiguous return value, and require explicit testing for errors with -\cfunction{PyErr_Occurred()}. - -Exception state is maintained in per-thread storage (this is -equivalent to using global storage in an unthreaded application). A -thread can be in one of two states: an exception has occurred, or not. -The function \cfunction{PyErr_Occurred()} can be used to check for -this: it returns a borrowed reference to the exception type object -when an exception has occurred, and \NULL{} otherwise. There are a -number of functions to set the exception state: -\cfunction{PyErr_SetString()} is the most common (though not the most -general) function to set the exception state, and -\cfunction{PyErr_Clear()} clears the exception state. - -The full exception state consists of three objects (all of which can -be \NULL{}): the exception type, the corresponding exception -value, and the traceback. These have the same meanings as the Python -object \code{sys.exc_type}, \code{sys.exc_value}, -\code{sys.exc_traceback}; however, they are not the same: the Python -objects represent the last exception being handled by a Python -\keyword{try} \ldots\ \keyword{except} statement, while the \C{} level -exception state only exists while an exception is being passed on -between \C{} functions until it reaches the Python interpreter, which -takes care of transferring it to \code{sys.exc_type} and friends. - -Note that starting with Python 1.5, the preferred, thread-safe way to -access the exception state from Python code is to call the function -\function{sys.exc_info()}, which returns the per-thread exception state -for Python code. Also, the semantics of both ways to access the -exception state have changed so that a function which catches an -exception will save and restore its thread's exception state so as to -preserve the exception state of its caller. This prevents common bugs -in exception handling code caused by an innocent-looking function -overwriting the exception being handled; it also reduces the often -unwanted lifetime extension for objects that are referenced by the -stack frames in the traceback. - -As a general principle, a function that calls another function to -perform some task should check whether the called function raised an -exception, and if so, pass the exception state on to its caller. It -should discard any object references that it owns, and returns an -error indicator, but it should \emph{not} set another exception --- -that would overwrite the exception that was just raised, and lose -important information about the exact cause of the error. - -A simple example of detecting exceptions and passing them on is shown -in the \cfunction{sum_sequence()} example above. It so happens that -that example doesn't need to clean up any owned references when it -detects an error. The following example function shows some error -cleanup. First, to remind you why you like Python, we show the -equivalent Python code: - -\begin{verbatim} -def incr_item(dict, key): - try: - item = dict[key] - except KeyError: - item = 0 - return item + 1 -\end{verbatim} - -Here is the corresponding \C{} code, in all its glory: - -\begin{verbatim} -int incr_item(PyObject *dict, PyObject *key) -{ - /* Objects all initialized to NULL for Py_XDECREF */ - PyObject *item = NULL, *const_one = NULL, *incremented_item = NULL; - int rv = -1; /* Return value initialized to -1 (failure) */ - - item = PyObject_GetItem(dict, key); - if (item == NULL) { - /* Handle KeyError only: */ - if (!PyErr_ExceptionMatches(PyExc_KeyError)) goto error; - - /* Clear the error and use zero: */ - PyErr_Clear(); - item = PyInt_FromLong(0L); - if (item == NULL) goto error; - } - - const_one = PyInt_FromLong(1L); - if (const_one == NULL) goto error; - - incremented_item = PyNumber_Add(item, const_one); - if (incremented_item == NULL) goto error; - - if (PyObject_SetItem(dict, key, incremented_item) < 0) goto error; - rv = 0; /* Success */ - /* Continue with cleanup code */ - - error: - /* Cleanup code, shared by success and failure path */ - - /* Use Py_XDECREF() to ignore NULL references */ - Py_XDECREF(item); - Py_XDECREF(const_one); - Py_XDECREF(incremented_item); - - return rv; /* -1 for error, 0 for success */ -} -\end{verbatim} - -This example represents an endorsed use of the \keyword{goto} statement -in \C{}! It illustrates the use of -\cfunction{PyErr_ExceptionMatches()} and \cfunction{PyErr_Clear()} to -handle specific exceptions, and the use of \cfunction{Py_XDECREF()} to -dispose of owned references that may be \NULL{} (note the \samp{X} in -the name; \cfunction{Py_DECREF()} would crash when confronted with a -\NULL{} reference). It is important that the variables used to hold -owned references are initialized to \NULL{} for this to work; -likewise, the proposed return value is initialized to \code{-1} -(failure) and only set to success after the final call made is -successful. - - -\section{Embedding Python} -\label{embedding} - -The one important task that only embedders (as opposed to extension -writers) of the Python interpreter have to worry about is the -initialization, and possibly the finalization, of the Python -interpreter. Most functionality of the interpreter can only be used -after the interpreter has been initialized. - -The basic initialization function is \cfunction{Py_Initialize()}. -This initializes the table of loaded modules, and creates the -fundamental modules \module{__builtin__}\refbimodindex{__builtin__}, -\module{__main__}\refbimodindex{__main__} and -\module{sys}\refbimodindex{sys}. It also initializes the module -search path (\code{sys.path}).% -\indexiii{module}{search}{path} - -\cfunction{Py_Initialize()} does not set the ``script argument list'' -(\code{sys.argv}). If this variable is needed by Python code that -will be executed later, it must be set explicitly with a call to -\code{PySys_SetArgv(\var{argc}, \var{argv})} subsequent to the call -to \cfunction{Py_Initialize()}. - -On most systems (in particular, on \UNIX{} and Windows, although the -details are slightly different), \cfunction{Py_Initialize()} -calculates the module search path based upon its best guess for the -location of the standard Python interpreter executable, assuming that -the Python library is found in a fixed location relative to the Python -interpreter executable. In particular, it looks for a directory named -\file{lib/python1.5} (replacing \file{1.5} with the current -interpreter version) relative to the parent directory where the -executable named \file{python} is found on the shell command search -path (the environment variable \envvar{PATH}). - -For instance, if the Python executable is found in -\file{/usr/local/bin/python}, it will assume that the libraries are in -\file{/usr/local/lib/python1.5}. (In fact, this particular path -is also the ``fallback'' location, used when no executable file named -\file{python} is found along \envvar{PATH}.) The user can override -this behavior by setting the environment variable \envvar{PYTHONHOME}, -or insert additional directories in front of the standard path by -setting \envvar{PYTHONPATH}. - -The embedding application can steer the search by calling -\code{Py_SetProgramName(\var{file})} \emph{before} calling -\cfunction{Py_Initialize()}. Note that \envvar{PYTHONHOME} still -overrides this and \envvar{PYTHONPATH} is still inserted in front of -the standard path. An application that requires total control has to -provide its own implementation of \cfunction{Py_GetPath()}, -\cfunction{Py_GetPrefix()}, \cfunction{Py_GetExecPrefix()}, -\cfunction{Py_GetProgramFullPath()} (all defined in -\file{Modules/getpath.c}). - -Sometimes, it is desirable to ``uninitialize'' Python. For instance, -the application may want to start over (make another call to -\cfunction{Py_Initialize()}) or the application is simply done with its -use of Python and wants to free all memory allocated by Python. This -can be accomplished by calling \cfunction{Py_Finalize()}. The function -\cfunction{Py_IsInitialized()} returns true iff Python is currently in the -initialized state. More information about these functions is given in -a later chapter. - - -\chapter{The Very High Level Layer} -\label{veryhigh} - -The functions in this chapter will let you execute Python source code -given in a file or a buffer, but they will not let you interact in a -more detailed way with the interpreter. - -\begin{cfuncdesc}{int}{PyRun_AnyFile}{FILE *fp, char *filename} -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyRun_SimpleString}{char *command} -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyRun_SimpleFile}{FILE *fp, char *filename} -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyRun_InteractiveOne}{FILE *fp, char *filename} -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyRun_InteractiveLoop}{FILE *fp, char *filename} -\end{cfuncdesc} - -\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseString}{char *str, - int start} -\end{cfuncdesc} - -\begin{cfuncdesc}{struct _node*}{PyParser_SimpleParseFile}{FILE *fp, - char *filename, int start} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyRun_String}{char *str, int start, - PyObject *globals, - PyObject *locals} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyRun_File}{FILE *fp, char *filename, - int start, PyObject *globals, - PyObject *locals} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{Py_CompileString}{char *str, char *filename, - int start} -\end{cfuncdesc} - - -\chapter{Reference Counting} -\label{countingRefs} - -The macros in this section are used for managing reference counts -of Python objects. - -\begin{cfuncdesc}{void}{Py_INCREF}{PyObject *o} -Increment the reference count for object \var{o}. The object must -not be \NULL{}; if you aren't sure that it isn't \NULL{}, use -\cfunction{Py_XINCREF()}. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_XINCREF}{PyObject *o} -Increment the reference count for object \var{o}. The object may be -\NULL{}, in which case the macro has no effect. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_DECREF}{PyObject *o} -Decrement the reference count for object \var{o}. The object must -not be \NULL{}; if you aren't sure that it isn't \NULL{}, use -\cfunction{Py_XDECREF()}. If the reference count reaches zero, the -object's type's deallocation function (which must not be \NULL{}) is -invoked. - -\strong{Warning:} The deallocation function can cause arbitrary Python -code to be invoked (e.g. when a class instance with a \method{__del__()} -method is deallocated). While exceptions in such code are not -propagated, the executed code has free access to all Python global -variables. This means that any object that is reachable from a global -variable should be in a consistent state before \cfunction{Py_DECREF()} is -invoked. For example, code to delete an object from a list should -copy a reference to the deleted object in a temporary variable, update -the list data structure, and then call \cfunction{Py_DECREF()} for the -temporary variable. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_XDECREF}{PyObject *o} -Decrement the reference count for object \var{o}. The object may be -\NULL{}, in which case the macro has no effect; otherwise the effect -is the same as for \cfunction{Py_DECREF()}, and the same warning -applies. -\end{cfuncdesc} - -The following functions or macros are only for internal use: -\cfunction{_Py_Dealloc()}, \cfunction{_Py_ForgetReference()}, -\cfunction{_Py_NewReference()}, as well as the global variable -\cdata{_Py_RefTotal}. - -XXX Should mention Py_Malloc(), Py_Realloc(), Py_Free(), -PyMem_Malloc(), PyMem_Realloc(), PyMem_Free(), PyMem_NEW(), -PyMem_RESIZE(), PyMem_DEL(), PyMem_XDEL(). - - -\chapter{Exception Handling} -\label{exceptionHandling} - -The functions in this chapter will let you handle and raise Python -exceptions. It is important to understand some of the basics of -Python exception handling. It works somewhat like the \UNIX{} -\cdata{errno} variable: there is a global indicator (per thread) of the -last error that occurred. Most functions don't clear this on success, -but will set it to indicate the cause of the error on failure. Most -functions also return an error indicator, usually \NULL{} if they are -supposed to return a pointer, or \code{-1} if they return an integer -(exception: the \cfunction{PyArg_Parse*()} functions return \code{1} for -success and \code{0} for failure). When a function must fail because -some function it called failed, it generally doesn't set the error -indicator; the function it called already set it. - -The error indicator consists of three Python objects corresponding to -the Python variables \code{sys.exc_type}, \code{sys.exc_value} and -\code{sys.exc_traceback}. API functions exist to interact with the -error indicator in various ways. There is a separate error indicator -for each thread. - -% XXX Order of these should be more thoughtful. -% Either alphabetical or some kind of structure. - -\begin{cfuncdesc}{void}{PyErr_Print}{} -Print a standard traceback to \code{sys.stderr} and clear the error -indicator. Call this function only when the error indicator is set. -(Otherwise it will cause a fatal error!) -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyErr_Occurred}{} -Test whether the error indicator is set. If set, return the exception -\emph{type} (the first argument to the last call to one of the -\cfunction{PyErr_Set*()} functions or to \cfunction{PyErr_Restore()}). If -not set, return \NULL{}. You do not own a reference to the return -value, so you do not need to \cfunction{Py_DECREF()} it. -\strong{Note:} do not compare the return value to a specific -exception; use \cfunction{PyErr_ExceptionMatches()} instead, shown -below. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyErr_ExceptionMatches}{PyObject *exc} -Equivalent to -\samp{PyErr_GivenExceptionMatches(PyErr_Occurred(), \var{exc})}. -This should only be called when an exception is actually set. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyErr_GivenExceptionMatches}{PyObject *given, PyObject *exc} -Return true if the \var{given} exception matches the exception in -\var{exc}. If \var{exc} is a class object, this also returns true -when \var{given} is a subclass. If \var{exc} is a tuple, all -exceptions in the tuple (and recursively in subtuples) are searched -for a match. This should only be called when an exception is actually -set. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_NormalizeException}{PyObject**exc, PyObject**val, PyObject**tb} -Under certain circumstances, the values returned by -\cfunction{PyErr_Fetch()} below can be ``unnormalized'', meaning that -\code{*\var{exc}} is a class object but \code{*\var{val}} is not an -instance of the same class. This function can be used to instantiate -the class in that case. If the values are already normalized, nothing -happens. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_Clear}{} -Clear the error indicator. If the error indicator is not set, there -is no effect. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_Fetch}{PyObject **ptype, PyObject **pvalue, PyObject **ptraceback} -Retrieve the error indicator into three variables whose addresses are -passed. If the error indicator is not set, set all three variables to -\NULL{}. If it is set, it will be cleared and you own a reference to -each object retrieved. The value and traceback object may be \NULL{} -even when the type object is not. \strong{Note:} this function is -normally only used by code that needs to handle exceptions or by code -that needs to save and restore the error indicator temporarily. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_Restore}{PyObject *type, PyObject *value, PyObject *traceback} -Set the error indicator from the three objects. If the error -indicator is already set, it is cleared first. If the objects are -\NULL{}, the error indicator is cleared. Do not pass a \NULL{} type -and non-\NULL{} value or traceback. The exception type should be a -string or class; if it is a class, the value should be an instance of -that class. Do not pass an invalid exception type or value. -(Violating these rules will cause subtle problems later.) This call -takes away a reference to each object, i.e. you must own a reference -to each object before the call and after the call you no longer own -these references. (If you don't understand this, don't use this -function. I warned you.) \strong{Note:} this function is normally -only used by code that needs to save and restore the error indicator -temporarily. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_SetString}{PyObject *type, char *message} -This is the most common way to set the error indicator. The first -argument specifies the exception type; it is normally one of the -standard exceptions, e.g. \cdata{PyExc_RuntimeError}. You need not -increment its reference count. The second argument is an error -message; it is converted to a string object. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_SetObject}{PyObject *type, PyObject *value} -This function is similar to \cfunction{PyErr_SetString()} but lets you -specify an arbitrary Python object for the ``value'' of the exception. -You need not increment its reference count. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_SetNone}{PyObject *type} -This is a shorthand for \samp{PyErr_SetObject(\var{type}, Py_None)}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyErr_BadArgument}{} -This is a shorthand for \samp{PyErr_SetString(PyExc_TypeError, -\var{message})}, where \var{message} indicates that a built-in operation -was invoked with an illegal argument. It is mostly for internal use. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyErr_NoMemory}{} -This is a shorthand for \samp{PyErr_SetNone(PyExc_MemoryError)}; it -returns \NULL{} so an object allocation function can write -\samp{return PyErr_NoMemory();} when it runs out of memory. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyErr_SetFromErrno}{PyObject *type} -This is a convenience function to raise an exception when a \C{} library -function has returned an error and set the \C{} variable \cdata{errno}. -It constructs a tuple object whose first item is the integer -\cdata{errno} value and whose second item is the corresponding error -message (gotten from \cfunction{strerror()}), and then calls -\samp{PyErr_SetObject(\var{type}, \var{object})}. On \UNIX{}, when -the \cdata{errno} value is \constant{EINTR}, indicating an interrupted -system call, this calls \cfunction{PyErr_CheckSignals()}, and if that set -the error indicator, leaves it set to that. The function always -returns \NULL{}, so a wrapper function around a system call can write -\samp{return PyErr_SetFromErrno();} when the system call returns an -error. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_BadInternalCall}{} -This is a shorthand for \samp{PyErr_SetString(PyExc_TypeError, -\var{message})}, where \var{message} indicates that an internal -operation (e.g. a Python/C API function) was invoked with an illegal -argument. It is mostly for internal use. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyErr_CheckSignals}{} -This function interacts with Python's signal handling. It checks -whether a signal has been sent to the processes and if so, invokes the -corresponding signal handler. If the -\module{signal}\refbimodindex{signal} module is supported, this can -invoke a signal handler written in Python. In all cases, the default -effect for \constant{SIGINT} is to raise the -\exception{KeyboadInterrupt} exception. If an exception is raised the -error indicator is set and the function returns \code{1}; otherwise -the function returns \code{0}. The error indicator may or may not be -cleared if it was previously set. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyErr_SetInterrupt}{} -This function is obsolete (XXX or platform dependent?). It simulates -the effect of a \constant{SIGINT} signal arriving --- the next time -\cfunction{PyErr_CheckSignals()} is called, -\exception{KeyboadInterrupt} will be raised. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyErr_NewException}{char *name, - PyObject *base, - PyObject *dict} -This utility function creates and returns a new exception object. The -\var{name} argument must be the name of the new exception, a \C{} string -of the form \code{module.class}. The \var{base} and \var{dict} -arguments are normally \NULL{}. Normally, this creates a class -object derived from the root for all exceptions, the built-in name -\exception{Exception} (accessible in \C{} as \cdata{PyExc_Exception}). -In this case the \member{__module__} attribute of the new class is set to the -first part (up to the last dot) of the \var{name} argument, and the -class name is set to the last part (after the last dot). When the -user has specified the \code{-X} command line option to use string -exceptions, for backward compatibility, or when the \var{base} -argument is not a class object (and not \NULL{}), a string object -created from the entire \var{name} argument is returned. The -\var{base} argument can be used to specify an alternate base class. -The \var{dict} argument can be used to specify a dictionary of class -variables and methods. -\end{cfuncdesc} - - -\section{Standard Exceptions} -\label{standardExceptions} - -All standard Python exceptions are available as global variables whose -names are \samp{PyExc_} followed by the Python exception name. -These have the type \ctype{PyObject *}; they are all either class -objects or string objects, depending on the use of the \code{-X} -option to the interpreter. For completeness, here are all the -variables: -\cdata{PyExc_Exception}, -\cdata{PyExc_StandardError}, -\cdata{PyExc_ArithmeticError}, -\cdata{PyExc_LookupError}, -\cdata{PyExc_AssertionError}, -\cdata{PyExc_AttributeError}, -\cdata{PyExc_EOFError}, -\cdata{PyExc_FloatingPointError}, -\cdata{PyExc_IOError}, -\cdata{PyExc_ImportError}, -\cdata{PyExc_IndexError}, -\cdata{PyExc_KeyError}, -\cdata{PyExc_KeyboardInterrupt}, -\cdata{PyExc_MemoryError}, -\cdata{PyExc_NameError}, -\cdata{PyExc_OverflowError}, -\cdata{PyExc_RuntimeError}, -\cdata{PyExc_SyntaxError}, -\cdata{PyExc_SystemError}, -\cdata{PyExc_SystemExit}, -\cdata{PyExc_TypeError}, -\cdata{PyExc_ValueError}, -\cdata{PyExc_ZeroDivisionError}. - - -\chapter{Utilities} -\label{utilities} - -The functions in this chapter perform various utility tasks, such as -parsing function arguments and constructing Python values from \C{} -values. - -\section{OS Utilities} -\label{os} - -\begin{cfuncdesc}{int}{Py_FdIsInteractive}{FILE *fp, char *filename} -Return true (nonzero) if the standard I/O file \var{fp} with name -\var{filename} is deemed interactive. This is the case for files for -which \samp{isatty(fileno(\var{fp}))} is true. If the global flag -\cdata{Py_InteractiveFlag} is true, this function also returns true if -the \var{name} pointer is \NULL{} or if the name is equal to one of -the strings \code{"<stdin>"} or \code{"???"}. -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyOS_GetLastModificationTime}{char *filename} -Return the time of last modification of the file \var{filename}. -The result is encoded in the same way as the timestamp returned by -the standard \C{} library function \cfunction{time()}. -\end{cfuncdesc} - - -\section{Process Control} -\label{processControl} - -\begin{cfuncdesc}{void}{Py_FatalError}{char *message} -Print a fatal error message and kill the process. No cleanup is -performed. This function should only be invoked when a condition is -detected that would make it dangerous to continue using the Python -interpreter; e.g., when the object administration appears to be -corrupted. On \UNIX{}, the standard \C{} library function -\cfunction{abort()} is called which will attempt to produce a -\file{core} file. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_Exit}{int status} -Exit the current process. This calls \cfunction{Py_Finalize()} and -then calls the standard \C{} library function -\code{exit(\var{status})}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{Py_AtExit}{void (*func) ()} -Register a cleanup function to be called by \cfunction{Py_Finalize()}. -The cleanup function will be called with no arguments and should -return no value. At most 32 cleanup functions can be registered. -When the registration is successful, \cfunction{Py_AtExit()} returns -\code{0}; on failure, it returns \code{-1}. The cleanup function -registered last is called first. Each cleanup function will be called -at most once. Since Python's internal finallization will have -completed before the cleanup function, no Python APIs should be called -by \var{func}. -\end{cfuncdesc} - - -\section{Importing Modules} -\label{importing} - -\begin{cfuncdesc}{PyObject*}{PyImport_ImportModule}{char *name} -This is a simplified interface to \cfunction{PyImport_ImportModuleEx()} -below, leaving the \var{globals} and \var{locals} arguments set to -\NULL{}. When the \var{name} argument contains a dot (i.e., when -it specifies a submodule of a package), the \var{fromlist} argument is -set to the list \code{['*']} so that the return value is the named -module rather than the top-level package containing it as would -otherwise be the case. (Unfortunately, this has an additional side -effect when \var{name} in fact specifies a subpackage instead of a -submodule: the submodules specified in the package's \code{__all__} -variable are loaded.) Return a new reference to the imported module, -or \NULL{} with an exception set on failure (the module may still -be created in this case --- examine \code{sys.modules} to find out). -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_ImportModuleEx}{char *name, PyObject *globals, PyObject *locals, PyObject *fromlist} -Import a module. This is best described by referring to the built-in -Python function \function{__import__()}\bifuncindex{__import__}, as -the standard \function{__import__()} function calls this function -directly. - -The return value is a new reference to the imported module or -top-level package, or \NULL{} with an exception set on failure -(the module may still be created in this case). Like for -\function{__import__()}, the return value when a submodule of a -package was requested is normally the top-level package, unless a -non-empty \var{fromlist} was given. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_Import}{PyObject *name} -This is a higher-level interface that calls the current ``import hook -function''. It invokes the \function{__import__()} function from the -\code{__builtins__} of the current globals. This means that the -import is done using whatever import hooks are installed in the -current environment, e.g. by \module{rexec}\refstmodindex{rexec} or -\module{ihooks}\refstmodindex{ihooks}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_ReloadModule}{PyObject *m} -Reload a module. This is best described by referring to the built-in -Python function \function{reload()}\bifuncindex{reload}, as the standard -\function{reload()} function calls this function directly. Return a -new reference to the reloaded module, or \NULL{} with an exception set -on failure (the module still exists in this case). -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_AddModule}{char *name} -Return the module object corresponding to a module name. The -\var{name} argument may be of the form \code{package.module}). First -check the modules dictionary if there's one there, and if not, create -a new one and insert in in the modules dictionary. Because the former -action is most common, this does not return a new reference, and you -do not own the returned reference. Return \NULL{} with an -exception set on failure. \strong{Note:} this function returns -a ``borrowed'' reference. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_ExecCodeModule}{char *name, PyObject *co} -Given a module name (possibly of the form \code{package.module}) and a -code object read from a Python bytecode file or obtained from the -built-in function \function{compile()}\bifuncindex{compile}, load the -module. Return a new reference to the module object, or \NULL{} with -an exception set if an error occurred (the module may still be created -in this case). (This function would reload the module if it was -already imported.) -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyImport_GetMagicNumber}{} -Return the magic number for Python bytecode files (a.k.a. \file{.pyc} -and \file{.pyo} files). The magic number should be present in the -first four bytes of the bytecode file, in little-endian byte order. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyImport_GetModuleDict}{} -Return the dictionary used for the module administration -(a.k.a. \code{sys.modules}). Note that this is a per-interpreter -variable. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{_PyImport_Init}{} -Initialize the import mechanism. For internal use only. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyImport_Cleanup}{} -Empty the module table. For internal use only. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{_PyImport_Fini}{} -Finalize the import mechanism. For internal use only. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{_PyImport_FindExtension}{char *, char *} -For internal use only. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{_PyImport_FixupExtension}{char *, char *} -For internal use only. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyImport_ImportFrozenModule}{char *} -Load a frozen module. Return \code{1} for success, \code{0} if the -module is not found, and \code{-1} with an exception set if the -initialization failed. To access the imported module on a successful -load, use \cfunction{PyImport_ImportModule()}. -(Note the misnomer --- this function would reload the module if it was -already imported.) -\end{cfuncdesc} - -\begin{ctypedesc}{struct _frozen} -This is the structure type definition for frozen module descriptors, -as generated by the \program{freeze}\index{freeze utility} utility -(see \file{Tools/freeze/} in the Python source distribution). Its -definition is: - -\begin{verbatim} -struct _frozen { - char *name; - unsigned char *code; - int size; -}; -\end{verbatim} -\end{ctypedesc} - -\begin{cvardesc}{struct _frozen*}{PyImport_FrozenModules} -This pointer is initialized to point to an array of \ctype{struct -_frozen} records, terminated by one whose members are all \NULL{} -or zero. When a frozen module is imported, it is searched in this -table. Third-party code could play tricks with this to provide a -dynamically created collection of frozen modules. -\end{cvardesc} - - -\chapter{Abstract Objects Layer} -\label{abstract} - -The functions in this chapter interact with Python objects regardless -of their type, or with wide classes of object types (e.g. all -numerical types, or all sequence types). When used on object types -for which they do not apply, they will flag a Python exception. - -\section{Object Protocol} -\label{object} - -\begin{cfuncdesc}{int}{PyObject_Print}{PyObject *o, FILE *fp, int flags} -Print an object \var{o}, on file \var{fp}. Returns \code{-1} on error -The flags argument is used to enable certain printing -options. The only option currently supported is -\constant{Py_PRINT_RAW}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyObject_HasAttrString}{PyObject *o, char *attr_name} -Returns \code{1} if \var{o} has the attribute \var{attr_name}, and -\code{0} otherwise. This is equivalent to the Python expression -\samp{hasattr(\var{o}, \var{attr_name})}. -This function always succeeds. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyObject_GetAttrString}{PyObject *o, char *attr_name} -Retrieve an attribute named \var{attr_name} from object \var{o}. -Returns the attribute value on success, or \NULL{} on failure. -This is the equivalent of the Python expression -\samp{\var{o}.\var{attr_name}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_HasAttr}{PyObject *o, PyObject *attr_name} -Returns \code{1} if \var{o} has the attribute \var{attr_name}, and -\code{0} otherwise. This is equivalent to the Python expression -\samp{hasattr(\var{o}, \var{attr_name})}. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_GetAttr}{PyObject *o, PyObject *attr_name} -Retrieve an attribute named \var{attr_name} from object \var{o}. -Returns the attribute value on success, or \NULL{} on failure. -This is the equivalent of the Python expression -\samp{\var{o}.\var{attr_name}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_SetAttrString}{PyObject *o, char *attr_name, PyObject *v} -Set the value of the attribute named \var{attr_name}, for object -\var{o}, to the value \var{v}. Returns \code{-1} on failure. This is -the equivalent of the Python statement \samp{\var{o}.\var{attr_name} = -\var{v}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_SetAttr}{PyObject *o, PyObject *attr_name, PyObject *v} -Set the value of the attribute named \var{attr_name}, for -object \var{o}, -to the value \var{v}. Returns \code{-1} on failure. This is -the equivalent of the Python statement \samp{\var{o}.\var{attr_name} = -\var{v}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_DelAttrString}{PyObject *o, char *attr_name} -Delete attribute named \var{attr_name}, for object \var{o}. Returns -\code{-1} on failure. This is the equivalent of the Python -statement: \samp{del \var{o}.\var{attr_name}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_DelAttr}{PyObject *o, PyObject *attr_name} -Delete attribute named \var{attr_name}, for object \var{o}. Returns -\code{-1} on failure. This is the equivalent of the Python -statement \samp{del \var{o}.\var{attr_name}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_Cmp}{PyObject *o1, PyObject *o2, int *result} -Compare the values of \var{o1} and \var{o2} using a routine provided -by \var{o1}, if one exists, otherwise with a routine provided by -\var{o2}. The result of the comparison is returned in \var{result}. -Returns \code{-1} on failure. This is the equivalent of the Python -statement \samp{\var{result} = cmp(\var{o1}, \var{o2})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_Compare}{PyObject *o1, PyObject *o2} -Compare the values of \var{o1} and \var{o2} using a routine provided -by \var{o1}, if one exists, otherwise with a routine provided by -\var{o2}. Returns the result of the comparison on success. On error, -the value returned is undefined; use \cfunction{PyErr_Occurred()} to -detect an error. This is equivalent to the -Python expression \samp{cmp(\var{o1}, \var{o2})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_Repr}{PyObject *o} -Compute the string representation of object, \var{o}. Returns the -string representation on success, \NULL{} on failure. This is -the equivalent of the Python expression \samp{repr(\var{o})}. -Called by the \function{repr()}\bifuncindex{repr} built-in function -and by reverse quotes. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o} -Compute the string representation of object \var{o}. Returns the -string representation on success, \NULL{} on failure. This is -the equivalent of the Python expression \samp{str(\var{o})}. -Called by the \function{str()}\bifuncindex{str} built-in function and -by the \keyword{print} statement. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyCallable_Check}{PyObject *o} -Determine if the object \var{o}, is callable. Return \code{1} if the -object is callable and \code{0} otherwise. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_CallObject}{PyObject *callable_object, PyObject *args} -Call a callable Python object \var{callable_object}, with -arguments given by the tuple \var{args}. If no arguments are -needed, then args may be \NULL{}. Returns the result of the -call on success, or \NULL{} on failure. This is the equivalent -of the Python expression \samp{apply(\var{o}, \var{args})}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyObject_CallFunction}{PyObject *callable_object, char *format, ...} -Call a callable Python object \var{callable_object}, with a -variable number of \C{} arguments. The \C{} arguments are described -using a \cfunction{Py_BuildValue()} style format string. The format may -be \NULL{}, indicating that no arguments are provided. Returns the -result of the call on success, or \NULL{} on failure. This is -the equivalent of the Python expression \samp{apply(\var{o}, -\var{args})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_CallMethod}{PyObject *o, char *m, char *format, ...} -Call the method named \var{m} of object \var{o} with a variable number -of C arguments. The \C{} arguments are described by a -\cfunction{Py_BuildValue()} format string. The format may be \NULL{}, -indicating that no arguments are provided. Returns the result of the -call on success, or \NULL{} on failure. This is the equivalent of the -Python expression \samp{\var{o}.\var{method}(\var{args})}. -Note that Special method names, such as \method{__add__()}, -\method{__getitem__()}, and so on are not supported. The specific -abstract-object routines for these must be used. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_Hash}{PyObject *o} -Compute and return the hash value of an object \var{o}. On -failure, return \code{-1}. This is the equivalent of the Python -expression \samp{hash(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_IsTrue}{PyObject *o} -Returns \code{1} if the object \var{o} is considered to be true, and -\code{0} otherwise. This is equivalent to the Python expression -\samp{not not \var{o}}. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_Type}{PyObject *o} -On success, returns a type object corresponding to the object -type of object \var{o}. On failure, returns \NULL{}. This is -equivalent to the Python expression \samp{type(\var{o})}. -\bifuncindex{type} -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyObject_Length}{PyObject *o} -Return the length of object \var{o}. If the object \var{o} provides -both sequence and mapping protocols, the sequence length is -returned. On error, \code{-1} is returned. This is the equivalent -to the Python expression \samp{len(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyObject_GetItem}{PyObject *o, PyObject *key} -Return element of \var{o} corresponding to the object \var{key} or -\NULL{} on failure. This is the equivalent of the Python expression -\samp{\var{o}[\var{key}]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_SetItem}{PyObject *o, PyObject *key, PyObject *v} -Map the object \var{key} to the value \var{v}. -Returns \code{-1} on failure. This is the equivalent -of the Python statement \samp{\var{o}[\var{key}] = \var{v}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyObject_DelItem}{PyObject *o, PyObject *key, PyObject *v} -Delete the mapping for \var{key} from \var{o}. Returns \code{-1} on -failure. This is the equivalent of the Python statement \samp{del -\var{o}[\var{key}]}. -\end{cfuncdesc} - - -\section{Number Protocol} -\label{number} - -\begin{cfuncdesc}{int}{PyNumber_Check}{PyObject *o} -Returns \code{1} if the object \var{o} provides numeric protocols, and -false otherwise. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Add}{PyObject *o1, PyObject *o2} -Returns the result of adding \var{o1} and \var{o2}, or \NULL{} on -failure. This is the equivalent of the Python expression -\samp{\var{o1} + \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Subtract}{PyObject *o1, PyObject *o2} -Returns the result of subtracting \var{o2} from \var{o1}, or \NULL{} -on failure. This is the equivalent of the Python expression -\samp{\var{o1} - \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Multiply}{PyObject *o1, PyObject *o2} -Returns the result of multiplying \var{o1} and \var{o2}, or \NULL{} on -failure. This is the equivalent of the Python expression -\samp{\var{o1} * \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Divide}{PyObject *o1, PyObject *o2} -Returns the result of dividing \var{o1} by \var{o2}, or \NULL{} on -failure. -This is the equivalent of the Python expression \samp{\var{o1} / -\var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Remainder}{PyObject *o1, PyObject *o2} -Returns the remainder of dividing \var{o1} by \var{o2}, or \NULL{} on -failure. This is the equivalent of the Python expression -\samp{\var{o1} \% \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Divmod}{PyObject *o1, PyObject *o2} -See the built-in function \function{divmod()}\bifuncindex{divmod}. -Returns \NULL{} on failure. This is the equivalent of the Python -expression \samp{divmod(\var{o1}, \var{o2})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Power}{PyObject *o1, PyObject *o2, PyObject *o3} -See the built-in function \function{pow()}\bifuncindex{pow}. Returns -\NULL{} on failure. This is the equivalent of the Python expression -\samp{pow(\var{o1}, \var{o2}, \var{o3})}, where \var{o3} is optional. -If \var{o3} is to be ignored, pass \cdata{Py_None} in its place. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Negative}{PyObject *o} -Returns the negation of \var{o} on success, or \NULL{} on failure. -This is the equivalent of the Python expression \samp{-\var{o}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Positive}{PyObject *o} -Returns \var{o} on success, or \NULL{} on failure. -This is the equivalent of the Python expression \samp{+\var{o}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Absolute}{PyObject *o} -Returns the absolute value of \var{o}, or \NULL{} on failure. This is -the equivalent of the Python expression \samp{abs(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Invert}{PyObject *o} -Returns the bitwise negation of \var{o} on success, or \NULL{} on -failure. This is the equivalent of the Python expression -\samp{\~\var{o}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Lshift}{PyObject *o1, PyObject *o2} -Returns the result of left shifting \var{o1} by \var{o2} on success, -or \NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o1} << \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Rshift}{PyObject *o1, PyObject *o2} -Returns the result of right shifting \var{o1} by \var{o2} on success, -or \NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o1} >> \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_And}{PyObject *o1, PyObject *o2} -Returns the result of ``anding'' \var{o2} and \var{o2} on success and -\NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o1} and \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Xor}{PyObject *o1, PyObject *o2} -Returns the bitwise exclusive or of \var{o1} by \var{o2} on success, -or \NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o1} \^{ }\var{o2}}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyNumber_Or}{PyObject *o1, PyObject *o2} -Returns the result of \var{o1} and \var{o2} on success, or \NULL{} on -failure. This is the equivalent of the Python expression -\samp{\var{o1} or \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Coerce}{PyObject **p1, PyObject **p2} -This function takes the addresses of two variables of type -\ctype{PyObject*}. - -If the objects pointed to by \code{*\var{p1}} and \code{*\var{p2}} -have the same type, increment their reference count and return -\code{0} (success). If the objects can be converted to a common -numeric type, replace \code{*p1} and \code{*p2} by their converted -value (with 'new' reference counts), and return \code{0}. -If no conversion is possible, or if some other error occurs, -return \code{-1} (failure) and don't increment the reference counts. -The call \code{PyNumber_Coerce(\&o1, \&o2)} is equivalent to the -Python statement \samp{\var{o1}, \var{o2} = coerce(\var{o1}, -\var{o2})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Int}{PyObject *o} -Returns the \var{o} converted to an integer object on success, or -\NULL{} on failure. This is the equivalent of the Python -expression \samp{int(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Long}{PyObject *o} -Returns the \var{o} converted to a long integer object on success, -or \NULL{} on failure. This is the equivalent of the Python -expression \samp{long(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyNumber_Float}{PyObject *o} -Returns the \var{o} converted to a float object on success, or \NULL{} -on failure. This is the equivalent of the Python expression -\samp{float(\var{o})}. -\end{cfuncdesc} - - -\section{Sequence Protocol} -\label{sequence} - -\begin{cfuncdesc}{int}{PySequence_Check}{PyObject *o} -Return \code{1} if the object provides sequence protocol, and \code{0} -otherwise. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PySequence_Concat}{PyObject *o1, PyObject *o2} -Return the concatenation of \var{o1} and \var{o2} on success, and \NULL{} on -failure. This is the equivalent of the Python -expression \samp{\var{o1} + \var{o2}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PySequence_Repeat}{PyObject *o, int count} -Return the result of repeating sequence object \var{o} \var{count} -times, or \NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o} * \var{count}}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PySequence_GetItem}{PyObject *o, int i} -Return the \var{i}th element of \var{o}, or \NULL{} on failure. This -is the equivalent of the Python expression \samp{\var{o}[\var{i}]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PySequence_GetSlice}{PyObject *o, int i1, int i2} -Return the slice of sequence object \var{o} between \var{i1} and -\var{i2}, or \NULL{} on failure. This is the equivalent of the Python -expression \samp{\var{o}[\var{i1}:\var{i2}]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PySequence_SetItem}{PyObject *o, int i, PyObject *v} -Assign object \var{v} to the \var{i}th element of \var{o}. -Returns \code{-1} on failure. This is the equivalent of the Python -statement \samp{\var{o}[\var{i}] = \var{v}}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_DelItem}{PyObject *o, int i} -Delete the \var{i}th element of object \var{v}. Returns -\code{-1} on failure. This is the equivalent of the Python -statement \samp{del \var{o}[\var{i}]}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_SetSlice}{PyObject *o, int i1, int i2, PyObject *v} -Assign the sequence object \var{v} to the slice in sequence -object \var{o} from \var{i1} to \var{i2}. This is the equivalent of -the Python statement \samp{\var{o}[\var{i1}:\var{i2}] = \var{v}}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_DelSlice}{PyObject *o, int i1, int i2} -Delete the slice in sequence object \var{o} from \var{i1} to \var{i2}. -Returns \code{-1} on failure. This is the equivalent of the Python -statement \samp{del \var{o}[\var{i1}:\var{i2}]}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PySequence_Tuple}{PyObject *o} -Returns the \var{o} as a tuple on success, and \NULL{} on failure. -This is equivalent to the Python expression \code{tuple(\var{o})}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_Count}{PyObject *o, PyObject *value} -Return the number of occurrences of \var{value} in \var{o}, that is, -return the number of keys for which \code{\var{o}[\var{key}] == -\var{value}}. On failure, return \code{-1}. This is equivalent to -the Python expression \samp{\var{o}.count(\var{value})}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_In}{PyObject *o, PyObject *value} -Determine if \var{o} contains \var{value}. If an item in \var{o} is -equal to \var{value}, return \code{1}, otherwise return \code{0}. On -error, return \code{-1}. This is equivalent to the Python expression -\samp{\var{value} in \var{o}}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySequence_Index}{PyObject *o, PyObject *value} -Return the first index \var{i} for which \code{\var{o}[\var{i}] == -\var{value}}. On error, return \code{-1}. This is equivalent to -the Python expression \samp{\var{o}.index(\var{value})}. -\end{cfuncdesc} - - -\section{Mapping Protocol} -\label{mapping} - -\begin{cfuncdesc}{int}{PyMapping_Check}{PyObject *o} -Return \code{1} if the object provides mapping protocol, and \code{0} -otherwise. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyMapping_Length}{PyObject *o} -Returns the number of keys in object \var{o} on success, and \code{-1} -on failure. For objects that do not provide sequence protocol, -this is equivalent to the Python expression \samp{len(\var{o})}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyMapping_DelItemString}{PyObject *o, char *key} -Remove the mapping for object \var{key} from the object \var{o}. -Return \code{-1} on failure. This is equivalent to -the Python statement \samp{del \var{o}[\var{key}]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyMapping_DelItem}{PyObject *o, PyObject *key} -Remove the mapping for object \var{key} from the object \var{o}. -Return \code{-1} on failure. This is equivalent to -the Python statement \samp{del \var{o}[\var{key}]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyMapping_HasKeyString}{PyObject *o, char *key} -On success, return \code{1} if the mapping object has the key \var{key} -and \code{0} otherwise. This is equivalent to the Python expression -\samp{\var{o}.has_key(\var{key})}. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{int}{PyMapping_HasKey}{PyObject *o, PyObject *key} -Return \code{1} if the mapping object has the key \var{key} and -\code{0} otherwise. This is equivalent to the Python expression -\samp{\var{o}.has_key(\var{key})}. -This function always succeeds. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyMapping_Keys}{PyObject *o} -On success, return a list of the keys in object \var{o}. On -failure, return \NULL{}. This is equivalent to the Python -expression \samp{\var{o}.keys()}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyMapping_Values}{PyObject *o} -On success, return a list of the values in object \var{o}. On -failure, return \NULL{}. This is equivalent to the Python -expression \samp{\var{o}.values()}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyMapping_Items}{PyObject *o} -On success, return a list of the items in object \var{o}, where -each item is a tuple containing a key-value pair. On -failure, return \NULL{}. This is equivalent to the Python -expression \samp{\var{o}.items()}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyMapping_Clear}{PyObject *o} -Make object \var{o} empty. Returns \code{1} on success and \code{0} -on failure. This is equivalent to the Python statement -\samp{for key in \var{o}.keys(): del \var{o}[key]}. -\end{cfuncdesc} - - -\begin{cfuncdesc}{PyObject*}{PyMapping_GetItemString}{PyObject *o, char *key} -Return element of \var{o} corresponding to the object \var{key} or -\NULL{} on failure. This is the equivalent of the Python expression -\samp{\var{o}[\var{key}]}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyMapping_SetItemString}{PyObject *o, char *key, PyObject *v} -Map the object \var{key} to the value \var{v} in object \var{o}. -Returns \code{-1} on failure. This is the equivalent of the Python -statement \samp{\var{o}[\var{key}] = \var{v}}. -\end{cfuncdesc} - - -\section{Constructors} - -\begin{cfuncdesc}{PyObject*}{PyFile_FromString}{char *file_name, char *mode} -On success, returns a new file object that is opened on the -file given by \var{file_name}, with a file mode given by \var{mode}, -where \var{mode} has the same semantics as the standard \C{} routine -\cfunction{fopen()}. On failure, return \code{-1}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFile_FromFile}{FILE *fp, char *file_name, char *mode, int close_on_del} -Return a new file object for an already opened standard \C{} file -pointer, \var{fp}. A file name, \var{file_name}, and open mode, -\var{mode}, must be provided as well as a flag, \var{close_on_del}, -that indicates whether the file is to be closed when the file object -is destroyed. On failure, return \code{-1}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFloat_FromDouble}{double v} -Returns a new float object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyInt_FromLong}{long v} -Returns a new int object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_New}{int len} -Returns a new list of length \var{len} on success, and \NULL{} on -failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromLong}{long v} -Returns a new long object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromDouble}{double v} -Returns a new long object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_New}{} -Returns a new empty dictionary on success, and \NULL{} on -failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_FromString}{char *v} -Returns a new string object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_FromStringAndSize}{char *v, int len} -Returns a new string object with the value \var{v} and length -\var{len} on success, and \NULL{} on failure. If \var{v} is \NULL{}, -the contents of the string are uninitialized. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyTuple_New}{int len} -Returns a new tuple of length \var{len} on success, and \NULL{} on -failure. -\end{cfuncdesc} - - -\chapter{Concrete Objects Layer} -\label{concrete} - -The functions in this chapter are specific to certain Python object -types. Passing them an object of the wrong type is not a good idea; -if you receive an object from a Python program and you are not sure -that it has the right type, you must perform a type check first; -e.g. to check that an object is a dictionary, use -\cfunction{PyDict_Check()}. The chapter is structured like the -``family tree'' of Python object types. - - -\section{Fundamental Objects} -\label{fundamental} - -This section describes Python type objects and the singleton object -\code{None}. - - -\subsection{Type Objects} -\label{typeObjects} - -\begin{ctypedesc}{PyTypeObject} - -\end{ctypedesc} - -\begin{cvardesc}{PyObject *}{PyType_Type} - -\end{cvardesc} - - -\subsection{The None Object} -\label{noneObject} - -\begin{cvardesc}{PyObject *}{Py_None} -The Python \code{None} object, denoting lack of value. This object has -no methods. -\end{cvardesc} - - -\section{Sequence Objects} -\label{sequenceObjects} - -Generic operations on sequence objects were discussed in the previous -chapter; this section deals with the specific kinds of sequence -objects that are intrinsic to the Python language. - - -\subsection{String Objects} -\label{stringObjects} - -\begin{ctypedesc}{PyStringObject} -This subtype of \ctype{PyObject} represents a Python string object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyString_Type} -This instance of \ctype{PyTypeObject} represents the Python string type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyString_Check}{PyObject *o} -Returns true if the object \var{o} is a string object. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_FromStringAndSize}{const char *v, - int len} -Returns a new string object with the value \var{v} and length -\var{len} on success, and \NULL{} on failure. If \var{v} is \NULL{}, -the contents of the string are uninitialized. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_FromString}{const char *v} -Returns a new string object with the value \var{v} on success, and -\NULL{} on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyString_Size}{PyObject *string} -Returns the length of the string in string object \var{string}. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{PyString_AsString}{PyObject *string} -Resturns a \NULL{} terminated representation of the contents of \var{string}. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyString_Concat}{PyObject **string, - PyObject *newpart} -Creates a new string object in \var{*string} containing the contents -of \var{newpart} appended to \var{string}. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyString_ConcatAndDel}{PyObject **string, - PyObject *newpart} -Creates a new string object in \var{*string} containing the contents -of \var{newpart} appended to \var{string}. This version decrements -the reference count of \var{newpart}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{_PyString_Resize}{PyObject **string, int newsize} -A way to resize a string object even though it is ``immutable''. -Only use this to build up a brand new string object; don't use this if -the string may already be known in other parts of the code. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_Format}{PyObject *format, - PyObject *args} -Returns a new string object from \var{format} and \var{args}. Analogous -to \code{\var{format} \% \var{args}}. The \var{args} argument must be -a tuple. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyString_InternInPlace}{PyObject **string} -Intern the argument \var{*string} in place. The argument must be the -address of a pointer variable pointing to a Python string object. -If there is an existing interned string that is the same as -\var{*string}, it sets \var{*string} to it (decrementing the reference -count of the old string object and incrementing the reference count of -the interned string object), otherwise it leaves \var{*string} alone -and interns it (incrementing its reference count). (Clarification: -even though there is a lot of talk about reference counts, think of -this function as reference-count-neutral; you own the object after -the call if and only if you owned it before the call.) -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyString_InternFromString}{const char *v} -A combination of \cfunction{PyString_FromString()} and -\cfunction{PyString_InternInPlace()}, returning either a new string object -that has been interned, or a new (``owned'') reference to an earlier -interned string object with the same value. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{PyString_AS_STRING}{PyObject *string} -Macro form of \cfunction{PyString_AsString()} but without error checking. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyString_GET_SIZE}{PyObject *string} -Macro form of \cfunction{PyString_GetSize()} but without error checking. -\end{cfuncdesc} - - - -\subsection{Tuple Objects} -\label{tupleObjects} - -\begin{ctypedesc}{PyTupleObject} -This subtype of \ctype{PyObject} represents a Python tuple object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyTuple_Type} -This instance of \ctype{PyTypeObject} represents the Python tuple type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyTuple_Check}{PyObject *p} -Return true if the argument is a tuple object. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyTuple_New}{int s} -Return a new tuple object of size \var{s}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyTuple_Size}{PyTupleObject *p} -Takes a pointer to a tuple object, and returns the size -of that tuple. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyTuple_GetItem}{PyTupleObject *p, int pos} -Returns the object at position \var{pos} in the tuple pointed -to by \var{p}. If \var{pos} is out of bounds, returns \NULL{} and -sets an \exception{IndexError} exception. \strong{Note:} this -function returns a ``borrowed'' reference. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyTuple_GET_ITEM}{PyTupleObject *p, int pos} -Does the same, but does no checking of its arguments. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyTuple_GetSlice}{PyTupleObject *p, - int low, - int high} -Takes a slice of the tuple pointed to by \var{p} from -\var{low} to \var{high} and returns it as a new tuple. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyTuple_SetItem}{PyTupleObject *p, - int pos, - PyObject *o} -Inserts a reference to object \var{o} at position \var{pos} of -the tuple pointed to by \var{p}. It returns \code{0} on success. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyTuple_SET_ITEM}{PyTupleObject *p, - int pos, - PyObject *o} - -Does the same, but does no error checking, and -should \emph{only} be used to fill in brand new tuples. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{_PyTuple_Resize}{PyTupleObject *p, - int new, - int last_is_sticky} -Can be used to resize a tuple. Because tuples are -\emph{supposed} to be immutable, this should only be used if there is only -one module referencing the object. Do \emph{not} use this if the tuple may -already be known to some other part of the code. \var{last_is_sticky} is -a flag --- if set, the tuple will grow or shrink at the front, otherwise -it will grow or shrink at the end. Think of this as destroying the old -tuple and creating a new one, only more efficiently. -\end{cfuncdesc} - - -\subsection{List Objects} -\label{listObjects} - -\begin{ctypedesc}{PyListObject} -This subtype of \ctype{PyObject} represents a Python list object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyList_Type} -This instance of \ctype{PyTypeObject} represents the Python list type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyList_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyListObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_New}{int size} -Returns a new list of length \var{len} on success, and \NULL{} on -failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_Size}{PyObject *list} -Returns the length of the list object in \var{list}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_GetItem}{PyObject *list, int index} -Returns the object at position \var{pos} in the list pointed -to by \var{p}. If \var{pos} is out of bounds, returns \NULL{} and -sets an \exception{IndexError} exception. \strong{Note:} this -function returns a ``borrowed'' reference. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_SetItem}{PyObject *list, int index, - PyObject *item} -Sets the item at index \var{index} in list to \var{item}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_Insert}{PyObject *list, int index, - PyObject *item} -Inserts the item \var{item} into list \var{list} in front of index -\var{index}. Returns 0 if successful; returns -1 and sets an -exception if unsuccessful. Analogous to \code{list.insert(index, item)}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_Append}{PyObject *list, PyObject *item} -Appends the object \var{item} at the end of list \var{list}. Returns -0 if successful; returns -1 and sets an exception if unsuccessful. -Analogous to \code{list.append(item)}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_GetSlice}{PyObject *list, - int low, int high} -Returns a list of the objects in \var{list} containing the objects -\emph{between} \var{low} and \var{high}. Returns NULL and sets an -exception if unsuccessful. -Analogous to \code{list[low:high]}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_SetSlice}{PyObject *list, - int low, int high, - PyObject *itemlist} -Sets the slice of \var{list} between \var{low} and \var{high} to the contents -of \var{itemlist}. Analogous to \code{list[low:high]=itemlist}. Returns 0 -on success, -1 on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_Sort}{PyObject *list} -Sorts the items of \var{list} in place. Returns 0 on success, -1 on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_Reverse}{PyObject *list} -Reverses the items of \var{list} in place. Returns 0 on success, -1 on failure. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_AsTuple}{PyObject *list} -Returns a new tuple object containing the contents of \var{list}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_GET_ITEM}{PyObject *list, int i} -Macro form of \cfunction{PyList_GetItem()} without error checking. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyList_SET_ITEM}{PyObject *list, int i, - PyObject *o} -Macro form of \cfunction{PyList_SetItem()} without error checking. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyList_GET_SIZE}{PyObject *list} -Macro form of \cfunction{PyList_GetSize()} without error checking. -\end{cfuncdesc} - - -\section{Mapping Objects} -\label{mapObjects} - -\subsection{Dictionary Objects} -\label{dictObjects} - -\begin{ctypedesc}{PyDictObject} -This subtype of \ctype{PyObject} represents a Python dictionary object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyDict_Type} -This instance of \ctype{PyTypeObject} represents the Python dictionary type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyDict_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyDictObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_New}{} -Returns a new empty dictionary. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyDict_Clear}{PyDictObject *p} -Empties an existing dictionary of all key/value pairs. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_SetItem}{PyDictObject *p, - PyObject *key, - PyObject *val} -Inserts \var{value} into the dictionary with a key of \var{key}. Both -\var{key} and \var{value} should be PyObjects, and \var{key} should be -hashable. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_SetItemString}{PyDictObject *p, - char *key, - PyObject *val} -Inserts \var{value} into the dictionary using \var{key} -as a key. \var{key} should be a \ctype{char *}. The key object is -created using \code{PyString_FromString(\var{key})}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_DelItem}{PyDictObject *p, PyObject *key} -Removes the entry in dictionary \var{p} with key \var{key}. -\var{key} is a PyObject. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_DelItemString}{PyDictObject *p, char *key} -Removes the entry in dictionary \var{p} which has a key -specified by the \ctype{char *}\var{key}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_GetItem}{PyDictObject *p, PyObject *key} -Returns the object from dictionary \var{p} which has a key -\var{key}. Returns \NULL{} if the key \var{key} is not present, but -without (!) setting an exception. \strong{Note:} this function -returns a ``borrowed'' reference. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_GetItemString}{PyDictObject *p, char *key} -This is the same as \cfunction{PyDict_GetItem()}, but \var{key} is -specified as a \ctype{char *}, rather than a \ctype{PyObject *}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_Items}{PyDictObject *p} -Returns a \ctype{PyListObject} containing all the items -from the dictionary, as in the dictinoary method \method{items()} (see -the \emph{Python Library Reference}). -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_Keys}{PyDictObject *p} -Returns a \ctype{PyListObject} containing all the keys -from the dictionary, as in the dictionary method \method{keys()} (see the -\emph{Python Library Reference}). -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyDict_Values}{PyDictObject *p} -Returns a \ctype{PyListObject} containing all the values -from the dictionary \var{p}, as in the dictionary method -\method{values()} (see the \emph{Python Library Reference}). -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_Size}{PyDictObject *p} -Returns the number of items in the dictionary. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyDict_Next}{PyDictObject *p, - int ppos, - PyObject **pkey, - PyObject **pvalue} - -\end{cfuncdesc} - - -\section{Numeric Objects} -\label{numericObjects} - -\subsection{Plain Integer Objects} -\label{intObjects} - -\begin{ctypedesc}{PyIntObject} -This subtype of \ctype{PyObject} represents a Python integer object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyInt_Type} -This instance of \ctype{PyTypeObject} represents the Python plain -integer type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyInt_Check}{PyObject *} - -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyInt_FromLong}{long ival} -Creates a new integer object with a value of \var{ival}. - -The current implementation keeps an array of integer objects for all -integers between \code{-1} and \code{100}, when you create an int in -that range you actually just get back a reference to the existing -object. So it should be possible to change the value of \code{1}. I -suspect the behaviour of Python in this case is undefined. :-) -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyInt_AS_LONG}{PyIntObject *io} -Returns the value of the object \var{io}. No error checking is -performed. -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyInt_AsLong}{PyObject *io} -Will first attempt to cast the object to a \ctype{PyIntObject}, if -it is not already one, and then return its value. -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyInt_GetMax}{} -Returns the systems idea of the largest integer it can handle -(\constant{LONG_MAX}, as defined in the system header files). -\end{cfuncdesc} - - -\subsection{Long Integer Objects} -\label{longObjects} - -\begin{ctypedesc}{PyLongObject} -This subtype of \ctype{PyObject} represents a Python long integer -object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyLong_Type} -This instance of \ctype{PyTypeObject} represents the Python long -integer type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyLong_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyLongObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromLong}{long v} -Returns a new \ctype{PyLongObject} object from \var{v}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromUnsignedLong}{unsigned long v} -Returns a new \ctype{PyLongObject} object from an unsigned \C{} long. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromDouble}{double v} -Returns a new \ctype{PyLongObject} object from the integer part of \var{v}. -\end{cfuncdesc} - -\begin{cfuncdesc}{long}{PyLong_AsLong}{PyObject *pylong} -Returns a \C{} \ctype{long} representation of the contents of \var{pylong}. -WHAT HAPPENS IF \var{pylong} is greater than \constant{LONG_MAX}? -\end{cfuncdesc} - -\begin{cfuncdesc}{unsigned long}{PyLong_AsUnsignedLong}{PyObject *pylong} -Returns a \C{} \ctype{unsigned long} representation of the contents of -\var{pylong}. WHAT HAPPENS IF \var{pylong} is greater than -\constant{ULONG_MAX}? -\end{cfuncdesc} - -\begin{cfuncdesc}{double}{PyLong_AsDouble}{PyObject *pylong} -Returns a \C{} \ctype{double} representation of the contents of \var{pylong}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyLong_FromString}{char *str, char **pend, - int base} -\end{cfuncdesc} - - -\subsection{Floating Point Objects} -\label{floatObjects} - -\begin{ctypedesc}{PyFloatObject} -This subtype of \ctype{PyObject} represents a Python floating point -object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyFloat_Type} -This instance of \ctype{PyTypeObject} represents the Python floating -point type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyFloat_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyFloatObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFloat_FromDouble}{double v} -Creates a \ctype{PyFloatObject} object from \var{v}. -\end{cfuncdesc} - -\begin{cfuncdesc}{double}{PyFloat_AsDouble}{PyObject *pyfloat} -Returns a \C{} \ctype{double} representation of the contents of \var{pyfloat}. -\end{cfuncdesc} - -\begin{cfuncdesc}{double}{PyFloat_AS_DOUBLE}{PyObject *pyfloat} -Returns a \C{} \ctype{double} representation of the contents of -\var{pyfloat}, but without error checking. -\end{cfuncdesc} - - -\subsection{Complex Number Objects} -\label{complexObjects} - -\begin{ctypedesc}{Py_complex} -The \C{} structure which corresponds to the value portion of a Python -complex number object. Most of the functions for dealing with complex -number objects use structures of this type as input or output values, -as appropriate. It is defined as: - -\begin{verbatim} -typedef struct { - double real; - double imag; -} Py_complex; -\end{verbatim} -\end{ctypedesc} - -\begin{ctypedesc}{PyComplexObject} -This subtype of \ctype{PyObject} represents a Python complex number object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyComplex_Type} -This instance of \ctype{PyTypeObject} represents the Python complex -number type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyComplex_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyComplexObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_sum}{Py_complex left, Py_complex right} -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_diff}{Py_complex left, Py_complex right} -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_neg}{Py_complex complex} -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_prod}{Py_complex left, Py_complex right} -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_quot}{Py_complex dividend, - Py_complex divisor} -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{_Py_c_pow}{Py_complex num, Py_complex exp} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyComplex_FromCComplex}{Py_complex v} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyComplex_FromDoubles}{double real, double imag} -Returns a new \ctype{PyComplexObject} object from \var{real} and \var{imag}. -\end{cfuncdesc} - -\begin{cfuncdesc}{double}{PyComplex_RealAsDouble}{PyObject *op} -Returns the real part of \var{op} as a \C{} \ctype{double}. -\end{cfuncdesc} - -\begin{cfuncdesc}{double}{PyComplex_ImagAsDouble}{PyObject *op} -Returns the imaginary part of \var{op} as a \C{} \ctype{double}. -\end{cfuncdesc} - -\begin{cfuncdesc}{Py_complex}{PyComplex_AsCComplex}{PyObject *op} -\end{cfuncdesc} - - - -\section{Other Objects} -\label{otherObjects} - -\subsection{File Objects} -\label{fileObjects} - -\begin{ctypedesc}{PyFileObject} -This subtype of \ctype{PyObject} represents a Python file object. -\end{ctypedesc} - -\begin{cvardesc}{PyTypeObject}{PyFile_Type} -This instance of \ctype{PyTypeObject} represents the Python file type. -\end{cvardesc} - -\begin{cfuncdesc}{int}{PyFile_Check}{PyObject *p} -Returns true if its argument is a \ctype{PyFileObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFile_FromString}{char *name, char *mode} -Creates a new \ctype{PyFileObject} pointing to the file -specified in \var{name} with the mode specified in \var{mode}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFile_FromFile}{FILE *fp, - char *name, char *mode, int (*close)} -Creates a new \ctype{PyFileObject} from the already-open \var{fp}. -The function \var{close} will be called when the file should be -closed. -\end{cfuncdesc} - -\begin{cfuncdesc}{FILE *}{PyFile_AsFile}{PyFileObject *p} -Returns the file object associated with \var{p} as a \ctype{FILE *}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFile_GetLine}{PyObject *p, int n} -undocumented as yet -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{PyFile_Name}{PyObject *p} -Returns the name of the file specified by \var{p} as a -\ctype{PyStringObject}. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyFile_SetBufSize}{PyFileObject *p, int n} -Available on systems with \cfunction{setvbuf()} only. This should -only be called immediately after file object creation. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyFile_SoftSpace}{PyFileObject *p, int newflag} -Sets the \member{softspace} attribute of \var{p} to \var{newflag}. -Returns the previous value. This function clears any errors, and will -return \code{0} as the previous value if the attribute either does not -exist or if there were errors in retrieving it. There is no way to -detect errors from this function, but doing so should not be needed. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyFile_WriteObject}{PyObject *obj, PyFileObject *p, - int flags} -Writes object \var{obj} to file object \var{p}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PyFile_WriteString}{char *s, PyFileObject *p, - int flags} -Writes string \var{s} to file object \var{p}. -\end{cfuncdesc} - - -\subsection{CObjects} -\label{cObjects} - -\begin{ctypedesc}{PyCObject} -This subtype of \ctype{PyObject} represents an opaque value, useful for -\C{} extension modules who need to pass an opaque value (as a -\ctype{void *} pointer) through Python code to other \C{} code. It is -often used to make a C function pointer defined in one module -available to other modules, so the regular import mechanism can be -used to access C APIs defined in dynamically loaded modules. -\end{ctypedesc} - -\begin{cfuncdesc}{PyObject *}{PyCObject_FromVoidPtr}{void* cobj, - void (*destr)(void *)} -Creates a \ctype{PyCObject} from the \code{void *} \var{cobj}. The -\var{destr} function will be called when the object is reclaimed. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject *}{PyCObject_FromVoidPtrAndDesc}{void* cobj, - void* desc, void (*destr)(void *, void *) } -Creates a \ctype{PyCObject} from the \ctype{void *}\var{cobj}. The -\var{destr} function will be called when the object is reclaimed. The -\var{desc} argument can be used to pass extra callback data for the -destructor function. -\end{cfuncdesc} - -\begin{cfuncdesc}{void *}{PyCObject_AsVoidPtr}{PyObject* self} -Returns the object \ctype{void *} that the \ctype{PyCObject} \var{self} -was created with. -\end{cfuncdesc} - -\begin{cfuncdesc}{void *}{PyCObject_GetDesc}{PyObject* self} -Returns the description \ctype{void *} that the \ctype{PyCObject} -\var{self} was created with. -\end{cfuncdesc} - -\chapter{Initialization, Finalization, and Threads} -\label{initialization} - -\begin{cfuncdesc}{void}{Py_Initialize}{} -Initialize the Python interpreter. In an application embedding -Python, this should be called before using any other Python/C API -functions; with the exception of \cfunction{Py_SetProgramName()}, -\cfunction{PyEval_InitThreads()}, \cfunction{PyEval_ReleaseLock()}, -and \cfunction{PyEval_AcquireLock()}. This initializes the table of -loaded modules (\code{sys.modules}), and creates the fundamental -modules \module{__builtin__}\refbimodindex{__builtin__}, -\module{__main__}\refbimodindex{__main__} and -\module{sys}\refbimodindex{sys}. It also initializes the module -search path (\code{sys.path}).% -\indexiii{module}{search}{path} -It does not set \code{sys.argv}; use \cfunction{PySys_SetArgv()} for -that. This is a no-op when called for a second time (without calling -\cfunction{Py_Finalize()} first). There is no return value; it is a -fatal error if the initialization fails. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{Py_IsInitialized}{} -Return true (nonzero) when the Python interpreter has been -initialized, false (zero) if not. After \cfunction{Py_Finalize()} is -called, this returns false until \cfunction{Py_Initialize()} is called -again. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_Finalize}{} -Undo all initializations made by \cfunction{Py_Initialize()} and -subsequent use of Python/C API functions, and destroy all -sub-interpreters (see \cfunction{Py_NewInterpreter()} below) that were -created and not yet destroyed since the last call to -\cfunction{Py_Initialize()}. Ideally, this frees all memory allocated -by the Python interpreter. This is a no-op when called for a second -time (without calling \cfunction{Py_Initialize()} again first). There -is no return value; errors during finalization are ignored. - -This function is provided for a number of reasons. An embedding -application might want to restart Python without having to restart the -application itself. An application that has loaded the Python -interpreter from a dynamically loadable library (or DLL) might want to -free all memory allocated by Python before unloading the DLL. During a -hunt for memory leaks in an application a developer might want to free -all memory allocated by Python before exiting from the application. - -\strong{Bugs and caveats:} The destruction of modules and objects in -modules is done in random order; this may cause destructors -(\method{__del__()} methods) to fail when they depend on other objects -(even functions) or modules. Dynamically loaded extension modules -loaded by Python are not unloaded. Small amounts of memory allocated -by the Python interpreter may not be freed (if you find a leak, please -report it). Memory tied up in circular references between objects is -not freed. Some memory allocated by extension modules may not be -freed. Some extension may not work properly if their initialization -routine is called more than once; this can happen if an applcation -calls \cfunction{Py_Initialize()} and \cfunction{Py_Finalize()} more -than once. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyThreadState*}{Py_NewInterpreter}{} -Create a new sub-interpreter. This is an (almost) totally separate -environment for the execution of Python code. In particular, the new -interpreter has separate, independent versions of all imported -modules, including the fundamental modules -\module{__builtin__}\refbimodindex{__builtin__}, -\module{__main__}\refbimodindex{__main__} and -\module{sys}\refbimodindex{sys}. The table of loaded modules -(\code{sys.modules}) and the module search path (\code{sys.path}) are -also separate. The new environment has no \code{sys.argv} variable. -It has new standard I/O stream file objects \code{sys.stdin}, -\code{sys.stdout} and \code{sys.stderr} (however these refer to the -same underlying \ctype{FILE} structures in the \C{} library). - -The return value points to the first thread state created in the new -sub-interpreter. This thread state is made the current thread state. -Note that no actual thread is created; see the discussion of thread -states below. If creation of the new interpreter is unsuccessful, -\NULL{} is returned; no exception is set since the exception state -is stored in the current thread state and there may not be a current -thread state. (Like all other Python/C API functions, the global -interpreter lock must be held before calling this function and is -still held when it returns; however, unlike most other Python/C API -functions, there needn't be a current thread state on entry.) - -Extension modules are shared between (sub-)interpreters as follows: -the first time a particular extension is imported, it is initialized -normally, and a (shallow) copy of its module's dictionary is -squirreled away. When the same extension is imported by another -(sub-)interpreter, a new module is initialized and filled with the -contents of this copy; the extension's \code{init} function is not -called. Note that this is different from what happens when an -extension is imported after the interpreter has been completely -re-initialized by calling \cfunction{Py_Finalize()} and -\cfunction{Py_Initialize()}; in that case, the extension's \code{init} -function \emph{is} called again. - -\strong{Bugs and caveats:} Because sub-interpreters (and the main -interpreter) are part of the same process, the insulation between them -isn't perfect --- for example, using low-level file operations like -\function{os.close()} they can (accidentally or maliciously) affect each -other's open files. Because of the way extensions are shared between -(sub-)interpreters, some extensions may not work properly; this is -especially likely when the extension makes use of (static) global -variables, or when the extension manipulates its module's dictionary -after its initialization. It is possible to insert objects created in -one sub-interpreter into a namespace of another sub-interpreter; this -should be done with great care to avoid sharing user-defined -functions, methods, instances or classes between sub-interpreters, -since import operations executed by such objects may affect the -wrong (sub-)interpreter's dictionary of loaded modules. (XXX This is -a hard-to-fix bug that will be addressed in a future release.) -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_EndInterpreter}{PyThreadState *tstate} -Destroy the (sub-)interpreter represented by the given thread state. -The given thread state must be the current thread state. See the -discussion of thread states below. When the call returns, the current -thread state is \NULL{}. All thread states associated with this -interpreted are destroyed. (The global interpreter lock must be held -before calling this function and is still held when it returns.) -\cfunction{Py_Finalize()} will destroy all sub-interpreters that haven't -been explicitly destroyed at that point. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{Py_SetProgramName}{char *name} -This function should be called before \cfunction{Py_Initialize()} is called -for the first time, if it is called at all. It tells the interpreter -the value of the \code{argv[0]} argument to the \cfunction{main()} function -of the program. This is used by \cfunction{Py_GetPath()} and some other -functions below to find the Python run-time libraries relative to the -interpreter executable. The default value is \code{"python"}. The -argument should point to a zero-terminated character string in static -storage whose contents will not change for the duration of the -program's execution. No code in the Python interpreter will change -the contents of this storage. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{Py_GetProgramName}{} -Return the program name set with \cfunction{Py_SetProgramName()}, or the -default. The returned string points into static storage; the caller -should not modify its value. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{Py_GetPrefix}{} -Return the \emph{prefix} for installed platform-independent files. This -is derived through a number of complicated rules from the program name -set with \cfunction{Py_SetProgramName()} and some environment variables; -for example, if the program name is \code{"/usr/local/bin/python"}, -the prefix is \code{"/usr/local"}. The returned string points into -static storage; the caller should not modify its value. This -corresponds to the \makevar{prefix} variable in the top-level -\file{Makefile} and the \code{-}\code{-prefix} argument to the -\program{configure} script at build time. The value is available to -Python code as \code{sys.prefix}. It is only useful on \UNIX{}. See -also the next function. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{Py_GetExecPrefix}{} -Return the \emph{exec-prefix} for installed platform-\emph{de}pendent -files. This is derived through a number of complicated rules from the -program name set with \cfunction{Py_SetProgramName()} and some environment -variables; for example, if the program name is -\code{"/usr/local/bin/python"}, the exec-prefix is -\code{"/usr/local"}. The returned string points into static storage; -the caller should not modify its value. This corresponds to the -\makevar{exec_prefix} variable in the top-level \file{Makefile} and the -\code{-}\code{-exec_prefix} argument to the \program{configure} script -at build time. The value is available to Python code as -\code{sys.exec_prefix}. It is only useful on \UNIX{}. - -Background: The exec-prefix differs from the prefix when platform -dependent files (such as executables and shared libraries) are -installed in a different directory tree. In a typical installation, -platform dependent files may be installed in the -\code{"/usr/local/plat"} subtree while platform independent may be -installed in \code{"/usr/local"}. - -Generally speaking, a platform is a combination of hardware and -software families, e.g. Sparc machines running the Solaris 2.x -operating system are considered the same platform, but Intel machines -running Solaris 2.x are another platform, and Intel machines running -Linux are yet another platform. Different major revisions of the same -operating system generally also form different platforms. Non-\UNIX{} -operating systems are a different story; the installation strategies -on those systems are so different that the prefix and exec-prefix are -meaningless, and set to the empty string. Note that compiled Python -bytecode files are platform independent (but not independent from the -Python version by which they were compiled!). - -System administrators will know how to configure the \program{mount} or -\program{automount} programs to share \code{"/usr/local"} between platforms -while having \code{"/usr/local/plat"} be a different filesystem for each -platform. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{Py_GetProgramFullPath}{} -Return the full program name of the Python executable; this is -computed as a side-effect of deriving the default module search path -from the program name (set by \cfunction{Py_SetProgramName()} above). The -returned string points into static storage; the caller should not -modify its value. The value is available to Python code as -\code{sys.executable}. -\end{cfuncdesc} - -\begin{cfuncdesc}{char*}{Py_GetPath}{} -\indexiii{module}{search}{path} -Return the default module search path; this is computed from the -program name (set by \cfunction{Py_SetProgramName()} above) and some -environment variables. The returned string consists of a series of -directory names separated by a platform dependent delimiter character. -The delimiter character is \character{:} on \UNIX{}, \character{;} on -DOS/Windows, and \character{\\n} (the \ASCII{} newline character) on -Macintosh. The returned string points into static storage; the caller -should not modify its value. The value is available to Python code -as the list \code{sys.path}, which may be modified to change the -future search path for loaded modules. - -% XXX should give the exact rules -\end{cfuncdesc} - -\begin{cfuncdesc}{const char*}{Py_GetVersion}{} -Return the version of this Python interpreter. This is a string that -looks something like - -\begin{verbatim} -"1.5 (#67, Dec 31 1997, 22:34:28) [GCC 2.7.2.2]" -\end{verbatim} - -The first word (up to the first space character) is the current Python -version; the first three characters are the major and minor version -separated by a period. The returned string points into static storage; -the caller should not modify its value. The value is available to -Python code as the list \code{sys.version}. -\end{cfuncdesc} - -\begin{cfuncdesc}{const char*}{Py_GetPlatform}{} -Return the platform identifier for the current platform. On \UNIX{}, -this is formed from the ``official'' name of the operating system, -converted to lower case, followed by the major revision number; e.g., -for Solaris 2.x, which is also known as SunOS 5.x, the value is -\code{"sunos5"}. On Macintosh, it is \code{"mac"}. On Windows, it -is \code{"win"}. The returned string points into static storage; -the caller should not modify its value. The value is available to -Python code as \code{sys.platform}. -\end{cfuncdesc} - -\begin{cfuncdesc}{const char*}{Py_GetCopyright}{} -Return the official copyright string for the current Python version, -for example - -\code{"Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam"} - -The returned string points into static storage; the caller should not -modify its value. The value is available to Python code as the list -\code{sys.copyright}. -\end{cfuncdesc} - -\begin{cfuncdesc}{const char*}{Py_GetCompiler}{} -Return an indication of the compiler used to build the current Python -version, in square brackets, for example: - -\begin{verbatim} -"[GCC 2.7.2.2]" -\end{verbatim} - -The returned string points into static storage; the caller should not -modify its value. The value is available to Python code as part of -the variable \code{sys.version}. -\end{cfuncdesc} - -\begin{cfuncdesc}{const char*}{Py_GetBuildInfo}{} -Return information about the sequence number and build date and time -of the current Python interpreter instance, for example - -\begin{verbatim} -"#67, Aug 1 1997, 22:34:28" -\end{verbatim} - -The returned string points into static storage; the caller should not -modify its value. The value is available to Python code as part of -the variable \code{sys.version}. -\end{cfuncdesc} - -\begin{cfuncdesc}{int}{PySys_SetArgv}{int argc, char **argv} -% XXX -\end{cfuncdesc} - -% XXX Other PySys thingies (doesn't really belong in this chapter) - -\section{Thread State and the Global Interpreter Lock} -\label{threads} - -The Python interpreter is not fully thread safe. In order to support -multi-threaded Python programs, there's a global lock that must be -held by the current thread before it can safely access Python objects. -Without the lock, even the simplest operations could cause problems in -a multi-threaded program: for example, when two threads simultaneously -increment the reference count of the same object, the reference count -could end up being incremented only once instead of twice. - -Therefore, the rule exists that only the thread that has acquired the -global interpreter lock may operate on Python objects or call Python/C -API functions. In order to support multi-threaded Python programs, -the interpreter regularly release and reacquires the lock --- by -default, every ten bytecode instructions (this can be changed with -\function{sys.setcheckinterval()}). The lock is also released and -reacquired around potentially blocking I/O operations like reading or -writing a file, so that other threads can run while the thread that -requests the I/O is waiting for the I/O operation to complete. - -The Python interpreter needs to keep some bookkeeping information -separate per thread --- for this it uses a data structure called -\ctype{PyThreadState}. This is new in Python 1.5; in earlier versions, -such state was stored in global variables, and switching threads could -cause problems. In particular, exception handling is now thread safe, -when the application uses \function{sys.exc_info()} to access the -exception last raised in the current thread. - -There's one global variable left, however: the pointer to the current -\ctype{PyThreadState} structure. While most thread packages have a way -to store ``per-thread global data,'' Python's internal platform -independent thread abstraction doesn't support this yet. Therefore, -the current thread state must be manipulated explicitly. - -This is easy enough in most cases. Most code manipulating the global -interpreter lock has the following simple structure: - -\begin{verbatim} -Save the thread state in a local variable. -Release the interpreter lock. -...Do some blocking I/O operation... -Reacquire the interpreter lock. -Restore the thread state from the local variable. -\end{verbatim} - -This is so common that a pair of macros exists to simplify it: - -\begin{verbatim} -Py_BEGIN_ALLOW_THREADS -...Do some blocking I/O operation... -Py_END_ALLOW_THREADS -\end{verbatim} - -The \code{Py_BEGIN_ALLOW_THREADS} macro opens a new block and declares -a hidden local variable; the \code{Py_END_ALLOW_THREADS} macro closes -the block. Another advantage of using these two macros is that when -Python is compiled without thread support, they are defined empty, -thus saving the thread state and lock manipulations. - -When thread support is enabled, the block above expands to the -following code: - -\begin{verbatim} -{ - PyThreadState *_save; - _save = PyEval_SaveThread(); - ...Do some blocking I/O operation... - PyEval_RestoreThread(_save); -} -\end{verbatim} - -Using even lower level primitives, we can get roughly the same effect -as follows: - -\begin{verbatim} -{ - PyThreadState *_save; - _save = PyThreadState_Swap(NULL); - PyEval_ReleaseLock(); - ...Do some blocking I/O operation... - PyEval_AcquireLock(); - PyThreadState_Swap(_save); -} -\end{verbatim} - -There are some subtle differences; in particular, -\cfunction{PyEval_RestoreThread()} saves and restores the value of the -global variable \cdata{errno}, since the lock manipulation does not -guarantee that \cdata{errno} is left alone. Also, when thread support -is disabled, \cfunction{PyEval_SaveThread()} and -\cfunction{PyEval_RestoreThread()} don't manipulate the lock; in this -case, \cfunction{PyEval_ReleaseLock()} and -\cfunction{PyEval_AcquireLock()} are not available. This is done so -that dynamically loaded extensions compiled with thread support -enabled can be loaded by an interpreter that was compiled with -disabled thread support. - -The global interpreter lock is used to protect the pointer to the -current thread state. When releasing the lock and saving the thread -state, the current thread state pointer must be retrieved before the -lock is released (since another thread could immediately acquire the -lock and store its own thread state in the global variable). -Reversely, when acquiring the lock and restoring the thread state, the -lock must be acquired before storing the thread state pointer. - -Why am I going on with so much detail about this? Because when -threads are created from \C{}, they don't have the global interpreter -lock, nor is there a thread state data structure for them. Such -threads must bootstrap themselves into existence, by first creating a -thread state data structure, then acquiring the lock, and finally -storing their thread state pointer, before they can start using the -Python/C API. When they are done, they should reset the thread state -pointer, release the lock, and finally free their thread state data -structure. - -When creating a thread data structure, you need to provide an -interpreter state data structure. The interpreter state data -structure hold global data that is shared by all threads in an -interpreter, for example the module administration -(\code{sys.modules}). Depending on your needs, you can either create -a new interpreter state data structure, or share the interpreter state -data structure used by the Python main thread (to access the latter, -you must obtain the thread state and access its \member{interp} member; -this must be done by a thread that is created by Python or by the main -thread after Python is initialized). - -XXX More? - -\begin{ctypedesc}{PyInterpreterState} -This data structure represents the state shared by a number of -cooperating threads. Threads belonging to the same interpreter -share their module administration and a few other internal items. -There are no public members in this structure. - -Threads belonging to different interpreters initially share nothing, -except process state like available memory, open file descriptors and -such. The global interpreter lock is also shared by all threads, -regardless of to which interpreter they belong. -\end{ctypedesc} - -\begin{ctypedesc}{PyThreadState} -This data structure represents the state of a single thread. The only -public data member is \ctype{PyInterpreterState *}\member{interp}, -which points to this thread's interpreter state. -\end{ctypedesc} - -\begin{cfuncdesc}{void}{PyEval_InitThreads}{} -Initialize and acquire the global interpreter lock. It should be -called in the main thread before creating a second thread or engaging -in any other thread operations such as -\cfunction{PyEval_ReleaseLock()} or -\code{PyEval_ReleaseThread(\var{tstate})}. It is not needed before -calling \cfunction{PyEval_SaveThread()} or -\cfunction{PyEval_RestoreThread()}. - -This is a no-op when called for a second time. It is safe to call -this function before calling \cfunction{Py_Initialize()}. - -When only the main thread exists, no lock operations are needed. This -is a common situation (most Python programs do not use threads), and -the lock operations slow the interpreter down a bit. Therefore, the -lock is not created initially. This situation is equivalent to having -acquired the lock: when there is only a single thread, all object -accesses are safe. Therefore, when this function initializes the -lock, it also acquires it. Before the Python -\module{thread}\refbimodindex{thread} module creates a new thread, -knowing that either it has the lock or the lock hasn't been created -yet, it calls \cfunction{PyEval_InitThreads()}. When this call -returns, it is guaranteed that the lock has been created and that it -has acquired it. - -It is \strong{not} safe to call this function when it is unknown which -thread (if any) currently has the global interpreter lock. - -This function is not available when thread support is disabled at -compile time. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyEval_AcquireLock}{} -Acquire the global interpreter lock. The lock must have been created -earlier. If this thread already has the lock, a deadlock ensues. -This function is not available when thread support is disabled at -compile time. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyEval_ReleaseLock}{} -Release the global interpreter lock. The lock must have been created -earlier. This function is not available when thread support is -disabled at compile time. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyEval_AcquireThread}{PyThreadState *tstate} -Acquire the global interpreter lock and then set the current thread -state to \var{tstate}, which should not be \NULL{}. The lock must -have been created earlier. If this thread already has the lock, -deadlock ensues. This function is not available when thread support -is disabled at compile time. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyEval_ReleaseThread}{PyThreadState *tstate} -Reset the current thread state to \NULL{} and release the global -interpreter lock. The lock must have been created earlier and must be -held by the current thread. The \var{tstate} argument, which must not -be \NULL{}, is only used to check that it represents the current -thread state --- if it isn't, a fatal error is reported. This -function is not available when thread support is disabled at compile -time. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyThreadState*}{PyEval_SaveThread}{} -Release the interpreter lock (if it has been created and thread -support is enabled) and reset the thread state to \NULL{}, -returning the previous thread state (which is not \NULL{}). If -the lock has been created, the current thread must have acquired it. -(This function is available even when thread support is disabled at -compile time.) -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyEval_RestoreThread}{PyThreadState *tstate} -Acquire the interpreter lock (if it has been created and thread -support is enabled) and set the thread state to \var{tstate}, which -must not be \NULL{}. If the lock has been created, the current -thread must not have acquired it, otherwise deadlock ensues. (This -function is available even when thread support is disabled at compile -time.) -\end{cfuncdesc} - -% XXX These aren't really C types, but the ctypedesc macro is the simplest! -\begin{ctypedesc}{Py_BEGIN_ALLOW_THREADS} -This macro expands to -\samp{\{ PyThreadState *_save; _save = PyEval_SaveThread();}. -Note that it contains an opening brace; it must be matched with a -following \code{Py_END_ALLOW_THREADS} macro. See above for further -discussion of this macro. It is a no-op when thread support is -disabled at compile time. -\end{ctypedesc} - -\begin{ctypedesc}{Py_END_ALLOW_THREADS} -This macro expands to -\samp{PyEval_RestoreThread(_save); \}}. -Note that it contains a closing brace; it must be matched with an -earlier \code{Py_BEGIN_ALLOW_THREADS} macro. See above for further -discussion of this macro. It is a no-op when thread support is -disabled at compile time. -\end{ctypedesc} - -\begin{ctypedesc}{Py_BEGIN_BLOCK_THREADS} -This macro expands to \samp{PyEval_RestoreThread(_save);} i.e. it -is equivalent to \code{Py_END_ALLOW_THREADS} without the closing -brace. It is a no-op when thread support is disabled at compile -time. -\end{ctypedesc} - -\begin{ctypedesc}{Py_BEGIN_UNBLOCK_THREADS} -This macro expands to \samp{_save = PyEval_SaveThread();} i.e. it is -equivalent to \code{Py_BEGIN_ALLOW_THREADS} without the opening brace -and variable declaration. It is a no-op when thread support is -disabled at compile time. -\end{ctypedesc} - -All of the following functions are only available when thread support -is enabled at compile time, and must be called only when the -interpreter lock has been created. - -\begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_New}{} -Create a new interpreter state object. The interpreter lock must be -held. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyInterpreterState_Clear}{PyInterpreterState *interp} -Reset all information in an interpreter state object. The interpreter -lock must be held. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyInterpreterState_Delete}{PyInterpreterState *interp} -Destroy an interpreter state object. The interpreter lock need not be -held. The interpreter state must have been reset with a previous -call to \cfunction{PyInterpreterState_Clear()}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyThreadState*}{PyThreadState_New}{PyInterpreterState *interp} -Create a new thread state object belonging to the given interpreter -object. The interpreter lock must be held. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyThreadState_Clear}{PyThreadState *tstate} -Reset all information in a thread state object. The interpreter lock -must be held. -\end{cfuncdesc} - -\begin{cfuncdesc}{void}{PyThreadState_Delete}{PyThreadState *tstate} -Destroy a thread state object. The interpreter lock need not be -held. The thread state must have been reset with a previous -call to \cfunction{PyThreadState_Clear()}. -\end{cfuncdesc} - -\begin{cfuncdesc}{PyThreadState*}{PyThreadState_Get}{} -Return the current thread state. The interpreter lock must be held. -When the current thread state is \NULL{}, this issues a fatal -error (so that the caller needn't check for \NULL{}). -\end{cfuncdesc} - -\begin{cfuncdesc}{PyThreadState*}{PyThreadState_Swap}{PyThreadState *tstate} -Swap the current thread state with the thread state given by the -argument \var{tstate}, which may be \NULL{}. The interpreter lock -must be held. -\end{cfuncdesc} - - -\chapter{Defining New Object Types} -\label{newTypes} - -\begin{cfuncdesc}{PyObject*}{_PyObject_New}{PyTypeObject *type} -\end{cfuncdesc} - -\begin{cfuncdesc}{PyObject*}{_PyObject_NewVar}{PyTypeObject *type, int size} -\end{cfuncdesc} - -\begin{cfuncdesc}{TYPE}{_PyObject_NEW}{TYPE, PyTypeObject *} -\end{cfuncdesc} - -\begin{cfuncdesc}{TYPE}{_PyObject_NEW_VAR}{TYPE, PyTypeObject *, int size} -\end{cfuncdesc} - -Py_InitModule (!!!) - -PyArg_ParseTupleAndKeywords, PyArg_ParseTuple, PyArg_Parse - -Py_BuildValue - -PyObject, PyVarObject - -PyObject_HEAD, PyObject_HEAD_INIT, PyObject_VAR_HEAD - -Typedefs: -unaryfunc, binaryfunc, ternaryfunc, inquiry, coercion, intargfunc, -intintargfunc, intobjargproc, intintobjargproc, objobjargproc, -getreadbufferproc, getwritebufferproc, getsegcountproc, -destructor, printfunc, getattrfunc, getattrofunc, setattrfunc, -setattrofunc, cmpfunc, reprfunc, hashfunc - -PyNumberMethods - -PySequenceMethods - -PyMappingMethods - -PyBufferProcs - -PyTypeObject - -DL_IMPORT - -PyType_Type - -Py*_Check - -Py_None, _Py_NoneStruct - - -\chapter{Debugging} -\label{debugging} - -XXX Explain Py_DEBUG, Py_TRACE_REFS, Py_REF_DEBUG. - - -\input{api.ind} % Index -- must be last - -\end{document} |