3 \title{Python/C API Reference Manual
}
7 \makeindex % tell \index to actually write the .idx file
15 \chapter*
{Front Matter
\label{front
}}
23 This manual documents the API used by C and
\Cpp{} programmers who
24 want to write extension modules or embed Python. It is a companion to
25 \citetitle[../ext/ext.html
]{Extending and Embedding the Python
26 Interpreter
}, which describes the general principles of extension
27 writing but does not
document the API functions in detail.
29 \strong{Warning:
} The current version of this
document is incomplete.
30 I hope that it is nevertheless useful. I will continue to work on it,
31 and release new versions from time to time, independent from Python
38 % XXX Consider moving all this back to ext.tex and giving api.tex
39 % XXX a *really* short intro only.
41 \chapter{Introduction
\label{intro
}}
43 The Application Programmer's Interface to Python gives C and
44 \Cpp{} programmers access to the Python interpreter at a variety of
45 levels. The API is equally usable from
\Cpp{}, but for brevity it is
46 generally referred to as the Python/C API. There are two
47 fundamentally different reasons for using the Python/C API. The first
48 reason is to write
\emph{extension modules
} for specific purposes;
49 these are C modules that extend the Python interpreter. This is
50 probably the most common use. The second reason is to use Python as a
51 component in a larger application; this technique is generally
52 referred to as
\dfn{embedding
} Python in an application.
54 Writing an extension module is a relatively well-understood process,
55 where a ``cookbook'' approach works well. There are several tools
56 that automate the process to some extent. While people have embedded
57 Python in other applications since its early existence, the process of
58 embedding Python is less straightforward than writing an extension.
60 Many API functions are useful independent of whether you're embedding
61 or extending Python; moreover, most applications that embed Python
62 will need to provide a custom extension as well, so it's probably a
63 good idea to become familiar with writing an extension before
64 attempting to embed Python in a real application.
67 \section{Include Files
\label{includes
}}
69 All function, type and macro definitions needed to use the Python/C
70 API are included in your code by the following line:
76 This implies inclusion of the following standard headers:
77 \code{<stdio.h>
},
\code{<string.h>
},
\code{<errno.h>
},
78 \code{<limits.h>
}, and
\code{<stdlib.h>
} (if available).
80 All user visible names defined by Python.h (except those defined by
81 the included standard headers) have one of the prefixes
\samp{Py
} or
82 \samp{_Py
}. Names beginning with
\samp{_Py
} are for internal use by
83 the Python implementation and should not be used by extension writers.
84 Structure member names do not have a reserved prefix.
86 \strong{Important:
} user code should never define names that begin
87 with
\samp{Py
} or
\samp{_Py
}. This confuses the reader, and
88 jeopardizes the portability of the user code to future Python
89 versions, which may define additional names beginning with one of
92 The header files are typically installed with Python. On
\UNIX, these
93 are located in the directories
94 \file{\envvar{prefix
}/include/python
\var{version
}/
} and
95 \file{\envvar{exec_prefix
}/include/python
\var{version
}/
}, where
96 \envvar{prefix
} and
\envvar{exec_prefix
} are defined by the
97 corresponding parameters to Python's
\program{configure
} script and
98 \var{version
} is
\code{sys.version
[:
3]}. On Windows, the headers are
99 installed in
\file{\envvar{prefix
}/include
}, where
\envvar{prefix
} is
100 the installation directory specified to the installer.
102 To include the headers, place both directories (if different) on your
103 compiler's search path for includes. Do
\emph{not
} place the parent
104 directories on the search path and then use
105 \samp{\#include <python
\shortversion/Python.h>
}; this will break on
106 multi-platform builds since the platform independent headers under
107 \envvar{prefix
} include the platform specific headers from
108 \envvar{exec_prefix
}.
110 \Cpp{} users should note that though the API is defined entirely using
111 C, the header files do properly declare the entry points to be
112 \code{extern "C"
}, so there is no need to do anything special to use
116 \section{Objects, Types and Reference Counts
\label{objects
}}
118 Most Python/C API functions have one or more arguments as well as a
119 return value of type
\ctype{PyObject*
}. This type is a pointer
120 to an opaque data type representing an arbitrary Python
121 object. Since all Python object types are treated the same way by the
122 Python language in most situations (e.g., assignments, scope rules,
123 and argument passing), it is only fitting that they should be
124 represented by a single C type. Almost all Python objects live on the
125 heap: you never declare an automatic or static variable of type
126 \ctype{PyObject
}, only pointer variables of type
\ctype{PyObject*
} can
127 be declared. The sole exception are the type objects
\obindex{type
};
128 since these must never be deallocated, they are typically static
129 \ctype{PyTypeObject
} objects.
131 All Python objects (even Python integers) have a
\dfn{type
} and a
132 \dfn{reference count
}. An object's type determines what kind of object
133 it is (e.g., an integer, a list, or a user-defined function; there are
134 many more as explained in the
\citetitle[../ref/ref.html
]{Python
135 Reference Manual
}). For each of the well-known types there is a macro
136 to check whether an object is of that type; for instance,
137 \samp{PyList_Check(
\var{a
})
} is true if (and only if) the object
138 pointed to by
\var{a
} is a Python list.
141 \subsection{Reference Counts
\label{refcounts
}}
143 The reference count is important because today's computers have a
144 finite (and often severely limited) memory size; it counts how many
145 different places there are that have a reference to an object. Such a
146 place could be another object, or a global (or static) C variable, or
147 a local variable in some C function. When an object's reference count
148 becomes zero, the object is deallocated. If it contains references to
149 other objects, their reference count is decremented. Those other
150 objects may be deallocated in turn, if this decrement makes their
151 reference count become zero, and so on. (There's an obvious problem
152 with objects that reference each other here; for now, the solution is
155 Reference counts are always manipulated explicitly. The normal way is
156 to use the macro
\cfunction{Py_INCREF()
}\ttindex{Py_INCREF()
} to
157 increment an object's reference count by one, and
158 \cfunction{Py_DECREF()
}\ttindex{Py_DECREF()
} to decrement it by
159 one. The
\cfunction{Py_DECREF()
} macro is considerably more complex
160 than the incref one, since it must check whether the reference count
161 becomes zero and then cause the object's deallocator to be called.
162 The deallocator is a function pointer contained in the object's type
163 structure. The type-specific deallocator takes care of decrementing
164 the reference counts for other objects contained in the object if this
165 is a compound object type, such as a list, as well as performing any
166 additional finalization that's needed. There's no chance that the
167 reference count can overflow; at least as many bits are used to hold
168 the reference count as there are distinct memory locations in virtual
169 memory (assuming
\code{sizeof(long) >= sizeof(char*)
}). Thus, the
170 reference count increment is a simple operation.
172 It is not necessary to increment an object's reference count for every
173 local variable that contains a pointer to an object. In theory, the
174 object's reference count goes up by one when the variable is made to
175 point to it and it goes down by one when the variable goes out of
176 scope. However, these two cancel each other out, so at the end the
177 reference count hasn't changed. The only real reason to use the
178 reference count is to prevent the object from being deallocated as
179 long as our variable is pointing to it. If we know that there is at
180 least one other reference to the object that lives at least as long as
181 our variable, there is no need to increment the reference count
182 temporarily. An important situation where this arises is in objects
183 that are passed as arguments to C functions in an extension module
184 that are called from Python; the call mechanism guarantees to hold a
185 reference to every argument for the duration of the call.
187 However, a common pitfall is to extract an object from a list and
188 hold on to it for a while without incrementing its reference count.
189 Some other operation might conceivably remove the object from the
190 list, decrementing its reference count and possible deallocating it.
191 The real danger is that innocent-looking operations may invoke
192 arbitrary Python code which could do this; there is a code path which
193 allows control to flow back to the user from a
\cfunction{Py_DECREF()
},
194 so almost any operation is potentially dangerous.
196 A safe approach is to always use the generic operations (functions
197 whose name begins with
\samp{PyObject_
},
\samp{PyNumber_
},
198 \samp{PySequence_
} or
\samp{PyMapping_
}). These operations always
199 increment the reference count of the object they return. This leaves
200 the caller with the responsibility to call
201 \cfunction{Py_DECREF()
} when they are done with the result; this soon
202 becomes second nature.
205 \subsubsection{Reference Count Details
\label{refcountDetails
}}
207 The reference count behavior of functions in the Python/C API is best
208 explained in terms of
\emph{ownership of references
}. Note that we
209 talk of owning references, never of owning objects; objects are always
210 shared! When a function owns a reference, it has to dispose of it
211 properly --- either by passing ownership on (usually to its caller) or
212 by calling
\cfunction{Py_DECREF()
} or
\cfunction{Py_XDECREF()
}. When
213 a function passes ownership of a reference on to its caller, the
214 caller is said to receive a
\emph{new
} reference. When no ownership
215 is transferred, the caller is said to
\emph{borrow
} the reference.
216 Nothing needs to be done for a borrowed reference.
218 Conversely, when a calling function passes it a reference to an
219 object, there are two possibilities: the function
\emph{steals
} a
220 reference to the object, or it does not. Few functions steal
221 references; the two notable exceptions are
222 \cfunction{PyList_SetItem()
}\ttindex{PyList_SetItem()
} and
223 \cfunction{PyTuple_SetItem()
}\ttindex{PyTuple_SetItem()
}, which
224 steal a reference to the item (but not to the tuple or list into which
225 the item is put!). These functions were designed to steal a reference
226 because of a common idiom for populating a tuple or list with newly
227 created objects; for example, the code to create the tuple
\code{(
1,
228 2, "three")
} could look like this (forgetting about error handling for
229 the moment; a better way to code this is shown below):
235 PyTuple_SetItem(t,
0, PyInt_FromLong(
1L));
236 PyTuple_SetItem(t,
1, PyInt_FromLong(
2L));
237 PyTuple_SetItem(t,
2, PyString_FromString("three"));
240 Incidentally,
\cfunction{PyTuple_SetItem()
} is the
\emph{only
} way to
241 set tuple items;
\cfunction{PySequence_SetItem()
} and
242 \cfunction{PyObject_SetItem()
} refuse to do this since tuples are an
243 immutable data type. You should only use
244 \cfunction{PyTuple_SetItem()
} for tuples that you are creating
247 Equivalent code for populating a list can be written using
248 \cfunction{PyList_New()
} and
\cfunction{PyList_SetItem()
}. Such code
249 can also use
\cfunction{PySequence_SetItem()
}; this illustrates the
250 difference between the two (the extra
\cfunction{Py_DECREF()
} calls):
256 x = PyInt_FromLong(
1L);
257 PySequence_SetItem(l,
0, x); Py_DECREF(x);
258 x = PyInt_FromLong(
2L);
259 PySequence_SetItem(l,
1, x); Py_DECREF(x);
260 x = PyString_FromString("three");
261 PySequence_SetItem(l,
2, x); Py_DECREF(x);
264 You might find it strange that the ``recommended'' approach takes more
265 code. However, in practice, you will rarely use these ways of
266 creating and populating a tuple or list. There's a generic function,
267 \cfunction{Py_BuildValue()
}, that can create most common objects from
268 C values, directed by a
\dfn{format string
}. For example, the
269 above two blocks of code could be replaced by the following (which
270 also takes care of the error checking):
275 t = Py_BuildValue("(iis)",
1,
2, "three");
276 l = Py_BuildValue("
[iis
]",
1,
2, "three");
279 It is much more common to use
\cfunction{PyObject_SetItem()
} and
280 friends with items whose references you are only borrowing, like
281 arguments that were passed in to the function you are writing. In
282 that case, their behaviour regarding reference counts is much saner,
283 since you don't have to increment a reference count so you can give a
284 reference away (``have it be stolen''). For example, this function
285 sets all items of a list (actually, any mutable sequence) to a given
289 int set_all(PyObject *target, PyObject *item)
293 n = PyObject_Length(target);
296 for (i =
0; i < n; i++)
{
297 if (PyObject_SetItem(target, i, item) <
0)
305 The situation is slightly different for function return values.
306 While passing a reference to most functions does not change your
307 ownership responsibilities for that reference, many functions that
308 return a referece to an object give you ownership of the reference.
309 The reason is simple: in many cases, the returned object is created
310 on the fly, and the reference you get is the only reference to the
311 object. Therefore, the generic functions that return object
312 references, like
\cfunction{PyObject_GetItem()
} and
313 \cfunction{PySequence_GetItem()
}, always return a new reference (the
314 caller becomes the owner of the reference).
316 It is important to realize that whether you own a reference returned
317 by a function depends on which function you call only ---
\emph{the
318 plumage
} (the type of the type of the object passed as an
319 argument to the function)
\emph{doesn't enter into it!
} Thus, if you
320 extract an item from a list using
\cfunction{PyList_GetItem()
}, you
321 don't own the reference --- but if you obtain the same item from the
322 same list using
\cfunction{PySequence_GetItem()
} (which happens to
323 take exactly the same arguments), you do own a reference to the
326 Here is an example of how you could write a function that computes the
327 sum of the items in a list of integers; once using
328 \cfunction{PyList_GetItem()
}\ttindex{PyList_GetItem()
}, and once using
329 \cfunction{PySequence_GetItem()
}\ttindex{PySequence_GetItem()
}.
332 long sum_list(PyObject *list)
338 n = PyList_Size(list);
340 return -
1; /* Not a list */
341 for (i =
0; i < n; i++)
{
342 item = PyList_GetItem(list, i); /* Can't fail */
343 if (!PyInt_Check(item)) continue; /* Skip non-integers */
344 total += PyInt_AsLong(item);
352 long sum_sequence(PyObject *sequence)
357 n = PySequence_Length(sequence);
359 return -
1; /* Has no length */
360 for (i =
0; i < n; i++)
{
361 item = PySequence_GetItem(sequence, i);
363 return -
1; /* Not a sequence, or other failure */
364 if (PyInt_Check(item))
365 total += PyInt_AsLong(item);
366 Py_DECREF(item); /* Discard reference ownership */
371 \ttindex{sum_sequence()
}
374 \subsection{Types
\label{types
}}
376 There are few other data types that play a significant role in
377 the Python/C API; most are simple C types such as
\ctype{int
},
378 \ctype{long
},
\ctype{double
} and
\ctype{char*
}. A few structure types
379 are used to describe static tables used to list the functions exported
380 by a module or the data attributes of a new object type, and another
381 is used to describe the value of a complex number. These will
382 be discussed together with the functions that use them.
385 \section{Exceptions
\label{exceptions
}}
387 The Python programmer only needs to deal with exceptions if specific
388 error handling is required; unhandled exceptions are automatically
389 propagated to the caller, then to the caller's caller, and so on, until
390 they reach the top-level interpreter, where they are reported to the
391 user accompanied by a stack traceback.
393 For C programmers, however, error checking always has to be explicit.
394 All functions in the Python/C API can raise exceptions, unless an
395 explicit claim is made otherwise in a function's documentation. In
396 general, when a function encounters an error, it sets an exception,
397 discards any object references that it owns, and returns an
398 error indicator --- usually
\NULL{} or
\code{-
1}. A few functions
399 return a Boolean true/false result, with false indicating an error.
400 Very few functions return no explicit error indicator or have an
401 ambiguous return value, and require explicit testing for errors with
402 \cfunction{PyErr_Occurred()
}\ttindex{PyErr_Occurred()
}.
404 Exception state is maintained in per-thread storage (this is
405 equivalent to using global storage in an unthreaded application). A
406 thread can be in one of two states: an exception has occurred, or not.
407 The function
\cfunction{PyErr_Occurred()
} can be used to check for
408 this: it returns a borrowed reference to the exception type object
409 when an exception has occurred, and
\NULL{} otherwise. There are a
410 number of functions to set the exception state:
411 \cfunction{PyErr_SetString()
}\ttindex{PyErr_SetString()
} is the most
412 common (though not the most general) function to set the exception
413 state, and
\cfunction{PyErr_Clear()
}\ttindex{PyErr_Clear()
} clears the
416 The full exception state consists of three objects (all of which can
417 be
\NULL{}): the exception type, the corresponding exception
418 value, and the traceback. These have the same meanings as the Python
419 \withsubitem{(in module sys)
}{
420 \ttindex{exc_type
}\ttindex{exc_value
}\ttindex{exc_traceback
}}
421 objects
\code{sys.exc_type
},
\code{sys.exc_value
}, and
422 \code{sys.exc_traceback
}; however, they are not the same: the Python
423 objects represent the last exception being handled by a Python
424 \keyword{try
} \ldots\
\keyword{except
} statement, while the C level
425 exception state only exists while an exception is being passed on
426 between C functions until it reaches the Python bytecode interpreter's
427 main loop, which takes care of transferring it to
\code{sys.exc_type
}
430 Note that starting with Python
1.5, the preferred, thread-safe way to
431 access the exception state from Python code is to call the function
432 \withsubitem{(in module sys)
}{\ttindex{exc_info()
}}
433 \function{sys.exc_info()
}, which returns the per-thread exception state
434 for Python code. Also, the semantics of both ways to access the
435 exception state have changed so that a function which catches an
436 exception will save and restore its thread's exception state so as to
437 preserve the exception state of its caller. This prevents common bugs
438 in exception handling code caused by an innocent-looking function
439 overwriting the exception being handled; it also reduces the often
440 unwanted lifetime extension for objects that are referenced by the
441 stack frames in the traceback.
443 As a general principle, a function that calls another function to
444 perform some task should check whether the called function raised an
445 exception, and if so, pass the exception state on to its caller. It
446 should discard any object references that it owns, and return an
447 error indicator, but it should
\emph{not
} set another exception ---
448 that would overwrite the exception that was just raised, and lose
449 important information about the exact cause of the error.
451 A simple example of detecting exceptions and passing them on is shown
452 in the
\cfunction{sum_sequence()
}\ttindex{sum_sequence()
} example
453 above. It so happens that that example doesn't need to clean up any
454 owned references when it detects an error. The following example
455 function shows some error cleanup. First, to remind you why you like
456 Python, we show the equivalent Python code:
459 def incr_item(dict, key):
466 \ttindex{incr_item()
}
468 Here is the corresponding C code, in all its glory:
471 int incr_item(PyObject *dict, PyObject *key)
473 /* Objects all initialized to NULL for Py_XDECREF */
474 PyObject *item = NULL, *const_one = NULL, *incremented_item = NULL;
475 int rv = -
1; /* Return value initialized to -
1 (failure) */
477 item = PyObject_GetItem(dict, key);
479 /* Handle KeyError only: */
480 if (!PyErr_ExceptionMatches(PyExc_KeyError))
483 /* Clear the error and use zero: */
485 item = PyInt_FromLong(
0L);
489 const_one = PyInt_FromLong(
1L);
490 if (const_one == NULL)
493 incremented_item = PyNumber_Add(item, const_one);
494 if (incremented_item == NULL)
497 if (PyObject_SetItem(dict, key, incremented_item) <
0)
499 rv =
0; /* Success */
500 /* Continue with cleanup code */
503 /* Cleanup code, shared by success and failure path */
505 /* Use Py_XDECREF() to ignore NULL references */
507 Py_XDECREF(const_one);
508 Py_XDECREF(incremented_item);
510 return rv; /* -
1 for error,
0 for success */
513 \ttindex{incr_item()
}
515 This example represents an endorsed use of the
\keyword{goto
} statement
516 in C! It illustrates the use of
517 \cfunction{PyErr_ExceptionMatches()
}\ttindex{PyErr_ExceptionMatches()
} and
518 \cfunction{PyErr_Clear()
}\ttindex{PyErr_Clear()
} to
519 handle specific exceptions, and the use of
520 \cfunction{Py_XDECREF()
}\ttindex{Py_XDECREF()
} to
521 dispose of owned references that may be
\NULL{} (note the
522 \character{X
} in the name;
\cfunction{Py_DECREF()
} would crash when
523 confronted with a
\NULL{} reference). It is important that the
524 variables used to hold owned references are initialized to
\NULL{} for
525 this to work; likewise, the proposed return value is initialized to
526 \code{-
1} (failure) and only set to success after the final call made
530 \section{Embedding Python
\label{embedding
}}
532 The one important task that only embedders (as opposed to extension
533 writers) of the Python interpreter have to worry about is the
534 initialization, and possibly the finalization, of the Python
535 interpreter. Most functionality of the interpreter can only be used
536 after the interpreter has been initialized.
538 The basic initialization function is
539 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
}.
540 This initializes the table of loaded modules, and creates the
541 fundamental modules
\module{__builtin__
}\refbimodindex{__builtin__
},
542 \module{__main__
}\refbimodindex{__main__
} and
543 \module{sys
}\refbimodindex{sys
}. It also initializes the module
544 search path (
\code{sys.path
}).
%
545 \indexiii{module
}{search
}{path
}
546 \withsubitem{(in module sys)
}{\ttindex{path
}}
548 \cfunction{Py_Initialize()
} does not set the ``script argument list''
549 (
\code{sys.argv
}). If this variable is needed by Python code that
550 will be executed later, it must be set explicitly with a call to
551 \code{PySys_SetArgv(
\var{argc
},
552 \var{argv
})
}\ttindex{PySys_SetArgv()
} subsequent to the call to
553 \cfunction{Py_Initialize()
}.
555 On most systems (in particular, on
\UNIX{} and Windows, although the
556 details are slightly different),
557 \cfunction{Py_Initialize()
} calculates the module search path based
558 upon its best guess for the location of the standard Python
559 interpreter executable, assuming that the Python library is found in a
560 fixed location relative to the Python interpreter executable. In
561 particular, it looks for a directory named
562 \file{lib/python
\shortversion} relative to the parent directory where
563 the executable named
\file{python
} is found on the shell command
564 search path (the environment variable
\envvar{PATH
}).
566 For instance, if the Python executable is found in
567 \file{/usr/local/bin/python
}, it will assume that the libraries are in
568 \file{/usr/local/lib/python
\shortversion}. (In fact, this particular path
569 is also the ``fallback'' location, used when no executable file named
570 \file{python
} is found along
\envvar{PATH
}.) The user can override
571 this behavior by setting the environment variable
\envvar{PYTHONHOME
},
572 or insert additional directories in front of the standard path by
573 setting
\envvar{PYTHONPATH
}.
575 The embedding application can steer the search by calling
576 \code{Py_SetProgramName(
\var{file
})
}\ttindex{Py_SetProgramName()
} \emph{before
} calling
577 \cfunction{Py_Initialize()
}. Note that
\envvar{PYTHONHOME
} still
578 overrides this and
\envvar{PYTHONPATH
} is still inserted in front of
579 the standard path. An application that requires total control has to
580 provide its own implementation of
581 \cfunction{Py_GetPath()
}\ttindex{Py_GetPath()
},
582 \cfunction{Py_GetPrefix()
}\ttindex{Py_GetPrefix()
},
583 \cfunction{Py_GetExecPrefix()
}\ttindex{Py_GetExecPrefix()
}, and
584 \cfunction{Py_GetProgramFullPath()
}\ttindex{Py_GetProgramFullPath()
} (all
585 defined in
\file{Modules/getpath.c
}).
587 Sometimes, it is desirable to ``uninitialize'' Python. For instance,
588 the application may want to start over (make another call to
589 \cfunction{Py_Initialize()
}) or the application is simply done with its
590 use of Python and wants to free all memory allocated by Python. This
591 can be accomplished by calling
\cfunction{Py_Finalize()
}. The function
592 \cfunction{Py_IsInitialized()
}\ttindex{Py_IsInitialized()
} returns
593 true if Python is currently in the initialized state. More
594 information about these functions is given in a later chapter.
597 \chapter{The Very High Level Layer
\label{veryhigh
}}
599 The functions in this chapter will let you execute Python source code
600 given in a file or a buffer, but they will not let you interact in a
601 more detailed way with the interpreter.
603 Several of these functions accept a start symbol from the grammar as a
604 parameter. The available start symbols are
\constant{Py_eval_input
},
605 \constant{Py_file_input
}, and
\constant{Py_single_input
}. These are
606 described following the functions which accept them as parameters.
608 Note also that several of these functions take
\ctype{FILE*
}
609 parameters. On particular issue which needs to be handled carefully
610 is that the
\ctype{FILE
} structure for different C libraries can be
611 different and incompatible. Under Windows (at least), it is possible
612 for dynamically linked extensions to actually use different libraries,
613 so care should be taken that
\ctype{FILE*
} parameters are only passed
614 to these functions if it is certain that they were created by the same
615 library that the Python runtime is using.
617 \begin{cfuncdesc
}{int
}{Py_Main
}{int argc, char **argv
}
618 The main program for the standard interpreter. This is made
619 available for programs which embed Python. The
\var{argc
} and
620 \var{argv
} parameters should be prepared exactly as those which are
621 passed to a C program's
\cfunction{main()
} function. It is
622 important to note that the argument list may be modified (but the
623 contents of the strings pointed to by the argument list are not).
624 The return value will be the integer passed to the
625 \function{sys.exit()
} function,
\code{1} if the interpreter exits
626 due to an exception, or
\code{2} if the parameter list does not
627 represent a valid Python command line.
630 \begin{cfuncdesc
}{int
}{PyRun_AnyFile
}{FILE *fp, char *filename
}
631 If
\var{fp
} refers to a file associated with an interactive device
632 (console or terminal input or
\UNIX{} pseudo-terminal), return the
633 value of
\cfunction{PyRun_InteractiveLoop()
}, otherwise return the
634 result of
\cfunction{PyRun_SimpleFile()
}. If
\var{filename
} is
635 \NULL{}, this function uses
\code{"???"
} as the filename.
638 \begin{cfuncdesc
}{int
}{PyRun_SimpleString
}{char *command
}
639 Executes the Python source code from
\var{command
} in the
640 \module{__main__
} module. If
\module{__main__
} does not already
641 exist, it is created. Returns
\code{0} on success or
\code{-
1} if
642 an exception was raised. If there was an error, there is no way to
643 get the exception information.
646 \begin{cfuncdesc
}{int
}{PyRun_SimpleFile
}{FILE *fp, char *filename
}
647 Similar to
\cfunction{PyRun_SimpleString()
}, but the Python source
648 code is read from
\var{fp
} instead of an in-memory string.
649 \var{filename
} should be the name of the file.
652 \begin{cfuncdesc
}{int
}{PyRun_InteractiveOne
}{FILE *fp, char *filename
}
653 Read and execute a single statement from a file associated with an
654 interactive device. If
\var{filename
} is
\NULL,
\code{"???"
} is
655 used instead. The user will be prompted using
\code{sys.ps1
} and
656 \code{sys.ps2
}. Returns
\code{0} when the input was executed
657 successfully,
\code{-
1} if there was an exception, or an error code
658 from the
\file{errcode.h
} include file distributed as part of Python
659 in case of a parse error. (Note that
\file{errcode.h
} is not
660 included by
\file{Python.h
}, so must be included specifically if
664 \begin{cfuncdesc
}{int
}{PyRun_InteractiveLoop
}{FILE *fp, char *filename
}
665 Read and execute statements from a file associated with an
666 interactive device until
\EOF{} is reached. If
\var{filename
} is
667 \NULL,
\code{"???"
} is used instead. The user will be prompted
668 using
\code{sys.ps1
} and
\code{sys.ps2
}. Returns
\code{0} at
\EOF.
671 \begin{cfuncdesc
}{struct _node*
}{PyParser_SimpleParseString
}{char *str,
673 Parse Python source code from
\var{str
} using the start token
674 \var{start
}. The result can be used to create a code object which
675 can be evaluated efficiently. This is useful if a code fragment
676 must be evaluated many times.
679 \begin{cfuncdesc
}{struct _node*
}{PyParser_SimpleParseFile
}{FILE *fp,
680 char *filename, int start
}
681 Similar to
\cfunction{PyParser_SimpleParseString()
}, but the Python
682 source code is read from
\var{fp
} instead of an in-memory string.
683 \var{filename
} should be the name of the file.
686 \begin{cfuncdesc
}{PyObject*
}{PyRun_String
}{char *str, int start,
689 Execute Python source code from
\var{str
} in the context specified
690 by the dictionaries
\var{globals
} and
\var{locals
}. The parameter
691 \var{start
} specifies the start token that should be used to parse
694 Returns the result of executing the code as a Python object, or
695 \NULL{} if an exception was raised.
698 \begin{cfuncdesc
}{PyObject*
}{PyRun_File
}{FILE *fp, char *filename,
699 int start, PyObject *globals,
701 Similar to
\cfunction{PyRun_String()
}, but the Python source code is
702 read from
\var{fp
} instead of an in-memory string.
703 \var{filename
} should be the name of the file.
706 \begin{cfuncdesc
}{PyObject*
}{Py_CompileString
}{char *str, char *filename,
708 Parse and compile the Python source code in
\var{str
}, returning the
709 resulting code object. The start token is given by
\var{start
};
710 this can be used to constrain the code which can be compiled and should
711 be
\constant{Py_eval_input
},
\constant{Py_file_input
}, or
712 \constant{Py_single_input
}. The filename specified by
713 \var{filename
} is used to construct the code object and may appear
714 in tracebacks or
\exception{SyntaxError
} exception messages. This
715 returns
\NULL{} if the code cannot be parsed or compiled.
718 \begin{cvardesc
}{int
}{Py_eval_input
}
719 The start symbol from the Python grammar for isolated expressions;
720 for use with
\cfunction{Py_CompileString()
}\ttindex{Py_CompileString()
}.
723 \begin{cvardesc
}{int
}{Py_file_input
}
724 The start symbol from the Python grammar for sequences of statements
725 as read from a file or other source; for use with
726 \cfunction{Py_CompileString()
}\ttindex{Py_CompileString()
}. This is
727 the symbol to use when compiling arbitrarily long Python source code.
730 \begin{cvardesc
}{int
}{Py_single_input
}
731 The start symbol from the Python grammar for a single statement; for
732 use with
\cfunction{Py_CompileString()
}\ttindex{Py_CompileString()
}.
733 This is the symbol used for the interactive interpreter loop.
737 \chapter{Reference Counting
\label{countingRefs
}}
739 The macros in this section are used for managing reference counts
742 \begin{cfuncdesc
}{void
}{Py_INCREF
}{PyObject *o
}
743 Increment the reference count for object
\var{o
}. The object must
744 not be
\NULL{}; if you aren't sure that it isn't
\NULL{}, use
745 \cfunction{Py_XINCREF()
}.
748 \begin{cfuncdesc
}{void
}{Py_XINCREF
}{PyObject *o
}
749 Increment the reference count for object
\var{o
}. The object may be
750 \NULL{}, in which case the macro has no effect.
753 \begin{cfuncdesc
}{void
}{Py_DECREF
}{PyObject *o
}
754 Decrement the reference count for object
\var{o
}. The object must
755 not be
\NULL{}; if you aren't sure that it isn't
\NULL{}, use
756 \cfunction{Py_XDECREF()
}. If the reference count reaches zero, the
757 object's type's deallocation function (which must not be
\NULL{}) is
760 \strong{Warning:
} The deallocation function can cause arbitrary Python
761 code to be invoked (e.g. when a class instance with a
762 \method{__del__()
} method is deallocated). While exceptions in such
763 code are not propagated, the executed code has free access to all
764 Python global variables. This means that any object that is reachable
765 from a global variable should be in a consistent state before
766 \cfunction{Py_DECREF()
} is invoked. For example, code to delete an
767 object from a list should copy a reference to the deleted object in a
768 temporary variable, update the list data structure, and then call
769 \cfunction{Py_DECREF()
} for the temporary variable.
772 \begin{cfuncdesc
}{void
}{Py_XDECREF
}{PyObject *o
}
773 Decrement the reference count for object
\var{o
}. The object may be
774 \NULL{}, in which case the macro has no effect; otherwise the effect
775 is the same as for
\cfunction{Py_DECREF()
}, and the same warning
779 The following functions or macros are only for use within the
780 interpreter core:
\cfunction{_Py_Dealloc()
},
781 \cfunction{_Py_ForgetReference()
},
\cfunction{_Py_NewReference()
}, as
782 well as the global variable
\cdata{_Py_RefTotal
}.
785 \chapter{Exception Handling
\label{exceptionHandling
}}
787 The functions described in this chapter will let you handle and raise Python
788 exceptions. It is important to understand some of the basics of
789 Python exception handling. It works somewhat like the
790 \UNIX{} \cdata{errno
} variable: there is a global indicator (per
791 thread) of the last error that occurred. Most functions don't clear
792 this on success, but will set it to indicate the cause of the error on
793 failure. Most functions also return an error indicator, usually
794 \NULL{} if they are supposed to return a pointer, or
\code{-
1} if they
795 return an integer (exception: the
\cfunction{PyArg_Parse*()
} functions
796 return
\code{1} for success and
\code{0} for failure). When a
797 function must fail because some function it called failed, it
798 generally doesn't set the error indicator; the function it called
801 The error indicator consists of three Python objects corresponding to
802 \withsubitem{(in module sys)
}{
803 \ttindex{exc_type
}\ttindex{exc_value
}\ttindex{exc_traceback
}}
804 the Python variables
\code{sys.exc_type
},
\code{sys.exc_value
} and
805 \code{sys.exc_traceback
}. API functions exist to interact with the
806 error indicator in various ways. There is a separate error indicator
809 % XXX Order of these should be more thoughtful.
810 % Either alphabetical or some kind of structure.
812 \begin{cfuncdesc
}{void
}{PyErr_Print
}{}
813 Print a standard traceback to
\code{sys.stderr
} and clear the error
814 indicator. Call this function only when the error indicator is set.
815 (Otherwise it will cause a fatal error!)
818 \begin{cfuncdesc
}{PyObject*
}{PyErr_Occurred
}{}
819 Test whether the error indicator is set. If set, return the exception
820 \emph{type
} (the first argument to the last call to one of the
821 \cfunction{PyErr_Set*()
} functions or to
\cfunction{PyErr_Restore()
}). If
822 not set, return
\NULL{}. You do not own a reference to the return
823 value, so you do not need to
\cfunction{Py_DECREF()
} it.
824 \strong{Note:
} Do not compare the return value to a specific
825 exception; use
\cfunction{PyErr_ExceptionMatches()
} instead, shown
826 below. (The comparison could easily fail since the exception may be
827 an instance instead of a class, in the case of a class exception, or
828 it may the a subclass of the expected exception.)
831 \begin{cfuncdesc
}{int
}{PyErr_ExceptionMatches
}{PyObject *exc
}
833 \samp{PyErr_GivenExceptionMatches(PyErr_Occurred(),
\var{exc
})
}.
834 This should only be called when an exception is actually set; a memory
835 access violation will occur if no exception has been raised.
838 \begin{cfuncdesc
}{int
}{PyErr_GivenExceptionMatches
}{PyObject *given, PyObject *exc
}
839 Return true if the
\var{given
} exception matches the exception in
840 \var{exc
}. If
\var{exc
} is a class object, this also returns true
841 when
\var{given
} is an instance of a subclass. If
\var{exc
} is a tuple, all
842 exceptions in the tuple (and recursively in subtuples) are searched
843 for a match. If
\var{given
} is
\NULL, a memory access violation will
847 \begin{cfuncdesc
}{void
}{PyErr_NormalizeException
}{PyObject**exc, PyObject**val, PyObject**tb
}
848 Under certain circumstances, the values returned by
849 \cfunction{PyErr_Fetch()
} below can be ``unnormalized'', meaning that
850 \code{*
\var{exc
}} is a class object but
\code{*
\var{val
}} is not an
851 instance of the same class. This function can be used to instantiate
852 the class in that case. If the values are already normalized, nothing
853 happens. The delayed normalization is implemented to improve
857 \begin{cfuncdesc
}{void
}{PyErr_Clear
}{}
858 Clear the error indicator. If the error indicator is not set, there
862 \begin{cfuncdesc
}{void
}{PyErr_Fetch
}{PyObject **ptype, PyObject **pvalue,
863 PyObject **ptraceback
}
864 Retrieve the error indicator into three variables whose addresses are
865 passed. If the error indicator is not set, set all three variables to
866 \NULL{}. If it is set, it will be cleared and you own a reference to
867 each object retrieved. The value and traceback object may be
868 \NULL{} even when the type object is not.
\strong{Note:
} This
869 function is normally only used by code that needs to handle exceptions
870 or by code that needs to save and restore the error indicator
874 \begin{cfuncdesc
}{void
}{PyErr_Restore
}{PyObject *type, PyObject *value,
876 Set the error indicator from the three objects. If the error
877 indicator is already set, it is cleared first. If the objects are
878 \NULL{}, the error indicator is cleared. Do not pass a
\NULL{} type
879 and non-
\NULL{} value or traceback. The exception type should be a
880 string or class; if it is a class, the value should be an instance of
881 that class. Do not pass an invalid exception type or value.
882 (Violating these rules will cause subtle problems later.) This call
883 takes away a reference to each object: you must own a reference
884 to each object before the call and after the call you no longer own
885 these references. (If you don't understand this, don't use this
886 function. I warned you.)
\strong{Note:
} This function is normally
887 only used by code that needs to save and restore the error indicator
891 \begin{cfuncdesc
}{void
}{PyErr_SetString
}{PyObject *type, char *message
}
892 This is the most common way to set the error indicator. The first
893 argument specifies the exception type; it is normally one of the
894 standard exceptions, e.g.
\cdata{PyExc_RuntimeError
}. You need not
895 increment its reference count. The second argument is an error
896 message; it is converted to a string object.
899 \begin{cfuncdesc
}{void
}{PyErr_SetObject
}{PyObject *type, PyObject *value
}
900 This function is similar to
\cfunction{PyErr_SetString()
} but lets you
901 specify an arbitrary Python object for the ``value'' of the exception.
902 You need not increment its reference count.
905 \begin{cfuncdesc
}{PyObject*
}{PyErr_Format
}{PyObject *exception,
906 const char *format,
\moreargs}
907 This function sets the error indicator.
\var{exception
} should be a
908 Python exception (string or class, not an instance).
909 \var{format
} should be a string, containing format codes, similar to
910 \cfunction{printf
}. The
\code{width.precision
} before a format code
911 is parsed, but the width part is ignored.
913 \begin{tableii
}{c|l
}{character
}{Character
}{Meaning
}
914 \lineii{c
}{Character, as an
\ctype{int
} parameter
}
915 \lineii{d
}{Number in decimal, as an
\ctype{int
} parameter
}
916 \lineii{x
}{Number in hexadecimal, as an
\ctype{int
} parameter
}
917 \lineii{x
}{A string, as a
\ctype{char *
} parameter
}
920 An unrecognized format character causes all the rest of
921 the format string to be copied as-is to the result string,
922 and any extra arguments discarded.
924 A new reference is returned, which is owned by the caller.
927 \begin{cfuncdesc
}{void
}{PyErr_SetNone
}{PyObject *type
}
928 This is a shorthand for
\samp{PyErr_SetObject(
\var{type
}, Py_None)
}.
931 \begin{cfuncdesc
}{int
}{PyErr_BadArgument
}{}
932 This is a shorthand for
\samp{PyErr_SetString(PyExc_TypeError,
933 \var{message
})
}, where
\var{message
} indicates that a built-in operation
934 was invoked with an illegal argument. It is mostly for internal use.
937 \begin{cfuncdesc
}{PyObject*
}{PyErr_NoMemory
}{}
938 This is a shorthand for
\samp{PyErr_SetNone(PyExc_MemoryError)
}; it
939 returns
\NULL{} so an object allocation function can write
940 \samp{return PyErr_NoMemory();
} when it runs out of memory.
943 \begin{cfuncdesc
}{PyObject*
}{PyErr_SetFromErrno
}{PyObject *type
}
944 This is a convenience function to raise an exception when a C library
945 function has returned an error and set the C variable
\cdata{errno
}.
946 It constructs a tuple object whose first item is the integer
947 \cdata{errno
} value and whose second item is the corresponding error
948 message (gotten from
\cfunction{strerror()
}\ttindex{strerror()
}), and
950 \samp{PyErr_SetObject(
\var{type
},
\var{object
})
}. On
\UNIX{}, when
951 the
\cdata{errno
} value is
\constant{EINTR
}, indicating an interrupted
952 system call, this calls
\cfunction{PyErr_CheckSignals()
}, and if that set
953 the error indicator, leaves it set to that. The function always
954 returns
\NULL{}, so a wrapper function around a system call can write
955 \samp{return PyErr_SetFromErrno();
} when the system call returns an
959 \begin{cfuncdesc
}{PyObject*
}{PyErr_SetFromErrnoWithFilename
}{PyObject *type,
961 Similar to
\cfunction{PyErr_SetFromErrno()
}, with the additional
962 behavior that if
\var{filename
} is not
\NULL, it is passed to the
963 constructor of
\var{type
} as a third parameter. In the case of
964 exceptions such as
\exception{IOError
} and
\exception{OSError
}, this
965 is used to define the
\member{filename
} attribute of the exception
969 \begin{cfuncdesc
}{void
}{PyErr_BadInternalCall
}{}
970 This is a shorthand for
\samp{PyErr_SetString(PyExc_TypeError,
971 \var{message
})
}, where
\var{message
} indicates that an internal
972 operation (e.g. a Python/C API function) was invoked with an illegal
973 argument. It is mostly for internal use.
976 \begin{cfuncdesc
}{int
}{PyErr_Warn
}{PyObject *category, char *message
}
977 Issue a warning message. The
\var{category
} argument is a warning
978 category (see below) or
\NULL; the
\var{message
} argument is a message
981 This function normally prints a warning message to
\var{sys.stderr
};
982 however, it is also possible that the user has specified that warnings
983 are to be turned into errors, and in that case this will raise an
984 exception. It is also possible that the function raises an exception
985 because of a problem with the warning machinery (the implementation
986 imports the
\module{warnings
} module to do the heavy lifting). The
987 return value is
\code{0} if no exception is raised, or
\code{-
1} if
988 an exception is raised. (It is not possible to determine whether a
989 warning message is actually printed, nor what the reason is for the
990 exception; this is intentional.) If an exception is raised, the
991 caller should do its normal exception handling
992 (e.g.
\cfunction{Py_DECREF()
} owned references and return an error
995 Warning categories must be subclasses of
\cdata{Warning
}; the default
996 warning category is
\cdata{RuntimeWarning
}. The standard Python
997 warning categories are available as global variables whose names are
998 \samp{PyExc_
} followed by the Python exception name. These have the
999 type
\ctype{PyObject*
}; they are all class objects. Their names are
1000 \cdata{PyExc_Warning
},
\cdata{PyExc_UserWarning
},
1001 \cdata{PyExc_DeprecationWarning
},
\cdata{PyExc_SyntaxWarning
}, and
1002 \cdata{PyExc_RuntimeWarning
}.
\cdata{PyExc_Warning
} is a subclass of
1003 \cdata{PyExc_Exception
}; the other warning categories are subclasses
1004 of
\cdata{PyExc_Warning
}.
1006 For information about warning control, see the documentation for the
1007 \module{warnings
} module and the
\programopt{-W
} option in the command
1008 line documentation. There is no C API for warning control.
1011 \begin{cfuncdesc
}{int
}{PyErr_WarnExplicit
}{PyObject *category, char *message,
1012 char *filename, int lineno, char *module, PyObject *registry
}
1013 Issue a warning message with explicit control over all warning
1014 attributes. This is a straightforward wrapper around the Python
1015 function
\function{warnings.warn_explicit()
}, see there for more
1016 information. The
\var{module
} and
\var{registry
} arguments may be
1017 set to
\code{NULL
} to get the default effect described there.
1020 \begin{cfuncdesc
}{int
}{PyErr_CheckSignals
}{}
1021 This function interacts with Python's signal handling. It checks
1022 whether a signal has been sent to the processes and if so, invokes the
1023 corresponding signal handler. If the
1024 \module{signal
}\refbimodindex{signal
} module is supported, this can
1025 invoke a signal handler written in Python. In all cases, the default
1026 effect for
\constant{SIGINT
}\ttindex{SIGINT
} is to raise the
1027 \withsubitem{(built-in exception)
}{\ttindex{KeyboardInterrupt
}}
1028 \exception{KeyboardInterrupt
} exception. If an exception is raised the
1029 error indicator is set and the function returns
\code{1}; otherwise
1030 the function returns
\code{0}. The error indicator may or may not be
1031 cleared if it was previously set.
1034 \begin{cfuncdesc
}{void
}{PyErr_SetInterrupt
}{}
1035 This function is obsolete. It simulates the effect of a
1036 \constant{SIGINT
}\ttindex{SIGINT
} signal arriving --- the next time
1037 \cfunction{PyErr_CheckSignals()
} is called,
1038 \withsubitem{(built-in exception)
}{\ttindex{KeyboardInterrupt
}}
1039 \exception{KeyboardInterrupt
} will be raised.
1040 It may be called without holding the interpreter lock.
1043 \begin{cfuncdesc
}{PyObject*
}{PyErr_NewException
}{char *name,
1046 This utility function creates and returns a new exception object. The
1047 \var{name
} argument must be the name of the new exception, a C string
1048 of the form
\code{module.class
}. The
\var{base
} and
1049 \var{dict
} arguments are normally
\NULL{}. This creates a
1050 class object derived from the root for all exceptions, the built-in
1051 name
\exception{Exception
} (accessible in C as
1052 \cdata{PyExc_Exception
}). The
\member{__module__
} attribute of the
1053 new class is set to the first part (up to the last dot) of the
1054 \var{name
} argument, and the class name is set to the last part (after
1055 the last dot). The
\var{base
} argument can be used to specify an
1056 alternate base class. The
\var{dict
} argument can be used to specify
1057 a dictionary of class variables and methods.
1060 \begin{cfuncdesc
}{void
}{PyErr_WriteUnraisable
}{PyObject *obj
}
1061 This utility function prints a warning message to
\var{sys.stderr
}
1062 when an exception has been set but it is impossible for the
1063 interpreter to actually raise the exception. It is used, for example,
1064 when an exception occurs in an
\member{__del__
} method.
1066 The function is called with a single argument
\var{obj
} that
1067 identifies where the context in which the unraisable exception
1068 occurred. The repr of
\var{obj
} will be printed in the warning
1072 \section{Standard Exceptions
\label{standardExceptions
}}
1074 All standard Python exceptions are available as global variables whose
1075 names are
\samp{PyExc_
} followed by the Python exception name. These
1076 have the type
\ctype{PyObject*
}; they are all class objects. For
1077 completeness, here are all the variables:
1079 \begin{tableiii
}{l|l|c
}{cdata
}{C Name
}{Python Name
}{Notes
}
1080 \lineiii{PyExc_Exception
}{\exception{Exception
}}{(
1)
}
1081 \lineiii{PyExc_StandardError
}{\exception{StandardError
}}{(
1)
}
1082 \lineiii{PyExc_ArithmeticError
}{\exception{ArithmeticError
}}{(
1)
}
1083 \lineiii{PyExc_LookupError
}{\exception{LookupError
}}{(
1)
}
1084 \lineiii{PyExc_AssertionError
}{\exception{AssertionError
}}{}
1085 \lineiii{PyExc_AttributeError
}{\exception{AttributeError
}}{}
1086 \lineiii{PyExc_EOFError
}{\exception{EOFError
}}{}
1087 \lineiii{PyExc_EnvironmentError
}{\exception{EnvironmentError
}}{(
1)
}
1088 \lineiii{PyExc_FloatingPointError
}{\exception{FloatingPointError
}}{}
1089 \lineiii{PyExc_IOError
}{\exception{IOError
}}{}
1090 \lineiii{PyExc_ImportError
}{\exception{ImportError
}}{}
1091 \lineiii{PyExc_IndexError
}{\exception{IndexError
}}{}
1092 \lineiii{PyExc_KeyError
}{\exception{KeyError
}}{}
1093 \lineiii{PyExc_KeyboardInterrupt
}{\exception{KeyboardInterrupt
}}{}
1094 \lineiii{PyExc_MemoryError
}{\exception{MemoryError
}}{}
1095 \lineiii{PyExc_NameError
}{\exception{NameError
}}{}
1096 \lineiii{PyExc_NotImplementedError
}{\exception{NotImplementedError
}}{}
1097 \lineiii{PyExc_OSError
}{\exception{OSError
}}{}
1098 \lineiii{PyExc_OverflowError
}{\exception{OverflowError
}}{}
1099 \lineiii{PyExc_RuntimeError
}{\exception{RuntimeError
}}{}
1100 \lineiii{PyExc_SyntaxError
}{\exception{SyntaxError
}}{}
1101 \lineiii{PyExc_SystemError
}{\exception{SystemError
}}{}
1102 \lineiii{PyExc_SystemExit
}{\exception{SystemExit
}}{}
1103 \lineiii{PyExc_TypeError
}{\exception{TypeError
}}{}
1104 \lineiii{PyExc_ValueError
}{\exception{ValueError
}}{}
1105 \lineiii{PyExc_WindowsError
}{\exception{WindowsError
}}{(
2)
}
1106 \lineiii{PyExc_ZeroDivisionError
}{\exception{ZeroDivisionError
}}{}
1113 This is a base class for other standard exceptions.
1116 Only defined on Windows; protect code that uses this by testing that
1117 the preprocessor macro
\code{MS_WINDOWS
} is defined.
1121 \section{Deprecation of String Exceptions
}
1123 All exceptions built into Python or provided in the standard library
1124 are derived from
\exception{Exception
}.
1125 \withsubitem{(built-in exception)
}{\ttindex{Exception
}}
1127 String exceptions are still supported in the interpreter to allow
1128 existing code to run unmodified, but this will also change in a future
1132 \chapter{Utilities
\label{utilities
}}
1134 The functions in this chapter perform various utility tasks, such as
1135 parsing function arguments and constructing Python values from C
1138 \section{OS Utilities
\label{os
}}
1140 \begin{cfuncdesc
}{int
}{Py_FdIsInteractive
}{FILE *fp, char *filename
}
1141 Return true (nonzero) if the standard I/O file
\var{fp
} with name
1142 \var{filename
} is deemed interactive. This is the case for files for
1143 which
\samp{isatty(fileno(
\var{fp
}))
} is true. If the global flag
1144 \cdata{Py_InteractiveFlag
} is true, this function also returns true if
1145 the
\var{filename
} pointer is
\NULL{} or if the name is equal to one of
1146 the strings
\code{'<stdin>'
} or
\code{'???'
}.
1149 \begin{cfuncdesc
}{long
}{PyOS_GetLastModificationTime
}{char *filename
}
1150 Return the time of last modification of the file
\var{filename
}.
1151 The result is encoded in the same way as the timestamp returned by
1152 the standard C library function
\cfunction{time()
}.
1155 \begin{cfuncdesc
}{void
}{PyOS_AfterFork
}{}
1156 Function to update some internal state after a process fork; this
1157 should be called in the new process if the Python interpreter will
1158 continue to be used. If a new executable is loaded into the new
1159 process, this function does not need to be called.
1162 \begin{cfuncdesc
}{int
}{PyOS_CheckStack
}{}
1163 Return true when the interpreter runs out of stack space. This is a
1164 reliable check, but is only available when
\code{USE_STACKCHECK
} is
1165 defined (currently on Windows using the Microsoft Visual C++ compiler
1166 and on the Macintosh).
\code{USE_CHECKSTACK
} will be defined
1167 automatically; you should never change the definition in your own
1171 \begin{cfuncdesc
}{PyOS_sighandler_t
}{PyOS_getsig
}{int i
}
1172 Return the current signal handler for signal
\var{i
}.
1173 This is a thin wrapper around either
\cfunction{sigaction
} or
1174 \cfunction{signal
}. Do not call those functions directly!
1175 \ctype{PyOS_sighandler_t
} is a typedef alias for
\ctype{void
(*)(int)}.
1178 \begin{cfuncdesc}{PyOS_sighandler_t}{PyOS_setsig}{int i, PyOS_sighandler_t h}
1179 Set the signal handler for signal \var{i} to be \var{h};
1180 return the old signal handler.
1181 This is a thin wrapper around either \cfunction{sigaction} or
1182 \cfunction{signal}. Do not call those functions directly!
1183 \ctype{PyOS_sighandler_t} is a typedef alias for \ctype{void (*)(int)}.
1187 \section{Process Control \label{processControl}}
1189 \begin{cfuncdesc}{void}{Py_FatalError}{char *message}
1190 Print a fatal error message and kill the process. No cleanup is
1191 performed. This function should only be invoked when a condition is
1192 detected that would make it dangerous to continue using the Python
1193 interpreter; e.g., when the object administration appears to be
1194 corrupted. On \UNIX{}, the standard C library function
1195 \cfunction{abort()}\ttindex{abort()} is called which will attempt to
1196 produce a \file{core} file.
1199 \begin{cfuncdesc}{void}{Py_Exit}{int status}
1200 Exit the current process. This calls
1201 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} and
1202 then calls the standard C library function
1203 \code{exit(\var{status})}\ttindex{exit()}.
1206 \begin{cfuncdesc}{int}{Py_AtExit}{void (*func) ()}
1207 Register a cleanup function to be called by
1208 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()}.
1209 The cleanup function will be called with no arguments and should
1210 return no value. At most 32 \index{cleanup functions}cleanup
1211 functions can be registered.
1212 When the registration is successful, \cfunction{Py_AtExit()} returns
1213 \code{0}; on failure, it returns \code{-1}. The cleanup function
1214 registered last is called first. Each cleanup function will be called
1215 at most once. Since Python's internal finallization will have
1216 completed before the cleanup function, no Python APIs should be called
1221 \section{Importing Modules \label{importing}}
1223 \begin{cfuncdesc}{PyObject*}{PyImport_ImportModule}{char *name}
1224 This is a simplified interface to
1225 \cfunction{PyImport_ImportModuleEx()} below, leaving the
1226 \var{globals} and \var{locals} arguments set to \NULL{}. When the
1227 \var{name} argument contains a dot (when it specifies a
1228 submodule of a package), the \var{fromlist} argument is set to the
1229 list \code{['*']} so that the return value is the named module rather
1230 than the top-level package containing it as would otherwise be the
1231 case. (Unfortunately, this has an additional side effect when
1232 \var{name} in fact specifies a subpackage instead of a submodule: the
1233 submodules specified in the package's \code{__all__} variable are
1234 \index{package variable!\code{__all__}}
1235 \withsubitem{(package variable)}{\ttindex{__all__}}loaded.) Return a
1236 new reference to the imported module, or
1237 \NULL{} with an exception set on failure (the module may still be
1238 created in this case --- examine \code{sys.modules} to find out).
1239 \withsubitem{(in module sys)}{\ttindex{modules}}
1242 \begin{cfuncdesc}{PyObject*}{PyImport_ImportModuleEx}{char *name, PyObject *globals, PyObject *locals, PyObject *fromlist}
1243 Import a module. This is best described by referring to the built-in
1244 Python function \function{__import__()}\bifuncindex{__import__}, as
1245 the standard \function{__import__()} function calls this function
1248 The return value is a new reference to the imported module or
1249 top-level package, or \NULL{} with an exception set on failure
1250 (the module may still be created in this case). Like for
1251 \function{__import__()}, the return value when a submodule of a
1252 package was requested is normally the top-level package, unless a
1253 non-empty \var{fromlist} was given.
1256 \begin{cfuncdesc}{PyObject*}{PyImport_Import}{PyObject *name}
1257 This is a higher-level interface that calls the current ``import hook
1258 function''. It invokes the \function{__import__()} function from the
1259 \code{__builtins__} of the current globals. This means that the
1260 import is done using whatever import hooks are installed in the
1261 current environment, e.g. by \module{rexec}\refstmodindex{rexec} or
1262 \module{ihooks}\refstmodindex{ihooks}.
1265 \begin{cfuncdesc}{PyObject*}{PyImport_ReloadModule}{PyObject *m}
1266 Reload a module. This is best described by referring to the built-in
1267 Python function \function{reload()}\bifuncindex{reload}, as the standard
1268 \function{reload()} function calls this function directly. Return a
1269 new reference to the reloaded module, or \NULL{} with an exception set
1270 on failure (the module still exists in this case).
1273 \begin{cfuncdesc}{PyObject*}{PyImport_AddModule}{char *name}
1274 Return the module object corresponding to a module name. The
1275 \var{name} argument may be of the form \code{package.module}). First
1276 check the modules dictionary if there's one there, and if not, create
1277 a new one and insert in in the modules dictionary.
1278 Warning: this function does not load or import the module; if the
1279 module wasn't already loaded, you will get an empty module object.
1280 Use \cfunction{PyImport_ImportModule()} or one of its variants to
1282 Return \NULL{} with an exception set on failure.
1285 \begin{cfuncdesc}{PyObject*}{PyImport_ExecCodeModule}{char *name, PyObject *co}
1286 Given a module name (possibly of the form \code{package.module}) and a
1287 code object read from a Python bytecode file or obtained from the
1288 built-in function \function{compile()}\bifuncindex{compile}, load the
1289 module. Return a new reference to the module object, or \NULL{} with
1290 an exception set if an error occurred (the module may still be created
1291 in this case). (This function would reload the module if it was
1295 \begin{cfuncdesc}{long}{PyImport_GetMagicNumber}{}
1296 Return the magic number for Python bytecode files (a.k.a.
1297 \file{.pyc} and \file{.pyo} files). The magic number should be
1298 present in the first four bytes of the bytecode file, in little-endian
1302 \begin{cfuncdesc}{PyObject*}{PyImport_GetModuleDict}{}
1303 Return the dictionary used for the module administration
1304 (a.k.a. \code{sys.modules}). Note that this is a per-interpreter
1308 \begin{cfuncdesc}{void}{_PyImport_Init}{}
1309 Initialize the import mechanism. For internal use only.
1312 \begin{cfuncdesc}{void}{PyImport_Cleanup}{}
1313 Empty the module table. For internal use only.
1316 \begin{cfuncdesc}{void}{_PyImport_Fini}{}
1317 Finalize the import mechanism. For internal use only.
1320 \begin{cfuncdesc}{PyObject*}{_PyImport_FindExtension}{char *, char *}
1321 For internal use only.
1324 \begin{cfuncdesc}{PyObject*}{_PyImport_FixupExtension}{char *, char *}
1325 For internal use only.
1328 \begin{cfuncdesc}{int}{PyImport_ImportFrozenModule}{char *name}
1329 Load a frozen module named \var{name}. Return \code{1} for success,
1330 \code{0} if the module is not found, and \code{-1} with an exception
1331 set if the initialization failed. To access the imported module on a
1332 successful load, use \cfunction{PyImport_ImportModule()}.
1333 (Note the misnomer --- this function would reload the module if it was
1337 \begin{ctypedesc}[_frozen]{struct _frozen}
1338 This is the structure type definition for frozen module descriptors,
1339 as generated by the \program{freeze}\index{freeze utility} utility
1340 (see \file{Tools/freeze/} in the Python source distribution). Its
1341 definition, found in \file{Include/import.h}, is:
1346 unsigned char *code;
1352 \begin{cvardesc}{struct _frozen*}{PyImport_FrozenModules}
1353 This pointer is initialized to point to an array of \ctype{struct
1354 _frozen} records, terminated by one whose members are all
1355 \NULL{} or zero. When a frozen module is imported, it is searched in
1356 this table. Third-party code could play tricks with this to provide a
1357 dynamically created collection of frozen modules.
1360 \begin{cfuncdesc}{int}{PyImport_AppendInittab}{char *name,
1361 void (*initfunc)(void)}
1362 Add a single module to the existing table of built-in modules. This
1363 is a convenience wrapper around \cfunction{PyImport_ExtendInittab()},
1364 returning \code{-1} if the table could not be extended. The new
1365 module can be imported by the name \var{name}, and uses the function
1366 \var{initfunc} as the initialization function called on the first
1367 attempted import. This should be called before
1368 \cfunction{Py_Initialize()}.
1371 \begin{ctypedesc}[_inittab]{struct _inittab}
1372 Structure describing a single entry in the list of built-in modules.
1373 Each of these structures gives the name and initialization function
1374 for a module built into the interpreter. Programs which embed Python
1375 may use an array of these structures in conjunction with
1376 \cfunction{PyImport_ExtendInittab()} to provide additional built-in
1377 modules. The structure is defined in \file{Include/import.h} as:
1382 void (*initfunc)(void);
1387 \begin{cfuncdesc}{int}{PyImport_ExtendInittab}{struct _inittab *newtab}
1388 Add a collection of modules to the table of built-in modules. The
1389 \var{newtab} array must end with a sentinel entry which contains
1390 \NULL{} for the \member{name} field; failure to provide the sentinel
1391 value can result in a memory fault. Returns \code{0} on success or
1392 \code{-1} if insufficient memory could be allocated to extend the
1393 internal table. In the event of failure, no modules are added to the
1394 internal table. This should be called before
1395 \cfunction{Py_Initialize()}.
1399 \chapter{Abstract Objects Layer \label{abstract}}
1401 The functions in this chapter interact with Python objects regardless
1402 of their type, or with wide classes of object types (e.g. all
1403 numerical types, or all sequence types). When used on object types
1404 for which they do not apply, they will raise a Python exception.
1406 \section{Object Protocol \label{object}}
1408 \begin{cfuncdesc}{int}{PyObject_Print}{PyObject *o, FILE *fp, int flags}
1409 Print an object \var{o}, on file \var{fp}. Returns \code{-1} on error.
1410 The flags argument is used to enable certain printing options. The
1411 only option currently supported is \constant{Py_PRINT_RAW}; if given,
1412 the \function{str()} of the object is written instead of the
1416 \begin{cfuncdesc}{int}{PyObject_HasAttrString}{PyObject *o, char *attr_name}
1417 Returns \code{1} if \var{o} has the attribute \var{attr_name}, and
1418 \code{0} otherwise. This is equivalent to the Python expression
1419 \samp{hasattr(\var{o}, \var{attr_name})}.
1420 This function always succeeds.
1423 \begin{cfuncdesc}{PyObject*}{PyObject_GetAttrString}{PyObject *o,
1425 Retrieve an attribute named \var{attr_name} from object \var{o}.
1426 Returns the attribute value on success, or \NULL{} on failure.
1427 This is the equivalent of the Python expression
1428 \samp{\var{o}.\var{attr_name}}.
1432 \begin{cfuncdesc}{int}{PyObject_HasAttr}{PyObject *o, PyObject *attr_name}
1433 Returns \code{1} if \var{o} has the attribute \var{attr_name}, and
1434 \code{0} otherwise. This is equivalent to the Python expression
1435 \samp{hasattr(\var{o}, \var{attr_name})}.
1436 This function always succeeds.
1440 \begin{cfuncdesc}{PyObject*}{PyObject_GetAttr}{PyObject *o,
1441 PyObject *attr_name}
1442 Retrieve an attribute named \var{attr_name} from object \var{o}.
1443 Returns the attribute value on success, or \NULL{} on failure.
1444 This is the equivalent of the Python expression
1445 \samp{\var{o}.\var{attr_name}}.
1449 \begin{cfuncdesc}{int}{PyObject_SetAttrString}{PyObject *o, char *attr_name, PyObject *v}
1450 Set the value of the attribute named \var{attr_name}, for object
1451 \var{o}, to the value \var{v}. Returns \code{-1} on failure. This is
1452 the equivalent of the Python statement \samp{\var{o}.\var{attr_name} =
1457 \begin{cfuncdesc}{int}{PyObject_SetAttr}{PyObject *o, PyObject *attr_name, PyObject *v}
1458 Set the value of the attribute named \var{attr_name}, for
1460 to the value \var{v}. Returns \code{-1} on failure. This is
1461 the equivalent of the Python statement \samp{\var{o}.\var{attr_name} =
1466 \begin{cfuncdesc}{int}{PyObject_DelAttrString}{PyObject *o, char *attr_name}
1467 Delete attribute named \var{attr_name}, for object \var{o}. Returns
1468 \code{-1} on failure. This is the equivalent of the Python
1469 statement: \samp{del \var{o}.\var{attr_name}}.
1473 \begin{cfuncdesc}{int}{PyObject_DelAttr}{PyObject *o, PyObject *attr_name}
1474 Delete attribute named \var{attr_name}, for object \var{o}. Returns
1475 \code{-1} on failure. This is the equivalent of the Python
1476 statement \samp{del \var{o}.\var{attr_name}}.
1480 \begin{cfuncdesc}{int}{PyObject_Cmp}{PyObject *o1, PyObject *o2, int *result}
1481 Compare the values of \var{o1} and \var{o2} using a routine provided
1482 by \var{o1}, if one exists, otherwise with a routine provided by
1483 \var{o2}. The result of the comparison is returned in \var{result}.
1484 Returns \code{-1} on failure. This is the equivalent of the Python
1485 statement\bifuncindex{cmp} \samp{\var{result} = cmp(\var{o1}, \var{o2})}.
1489 \begin{cfuncdesc}{int}{PyObject_Compare}{PyObject *o1, PyObject *o2}
1490 Compare the values of \var{o1} and \var{o2} using a routine provided
1491 by \var{o1}, if one exists, otherwise with a routine provided by
1492 \var{o2}. Returns the result of the comparison on success. On error,
1493 the value returned is undefined; use \cfunction{PyErr_Occurred()} to
1494 detect an error. This is equivalent to the Python
1495 expression\bifuncindex{cmp} \samp{cmp(\var{o1}, \var{o2})}.
1499 \begin{cfuncdesc}{PyObject*}{PyObject_Repr}{PyObject *o}
1500 Compute a string representation of object \var{o}. Returns the
1501 string representation on success, \NULL{} on failure. This is
1502 the equivalent of the Python expression \samp{repr(\var{o})}.
1503 Called by the \function{repr()}\bifuncindex{repr} built-in function
1504 and by reverse quotes.
1508 \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}
1509 Compute a string representation of object \var{o}. Returns the
1510 string representation on success, \NULL{} on failure. This is
1511 the equivalent of the Python expression \samp{str(\var{o})}.
1512 Called by the \function{str()}\bifuncindex{str} built-in function and
1513 by the \keyword{print} statement.
1517 \begin{cfuncdesc}{PyObject*}{PyObject_Unicode}{PyObject *o}
1518 Compute a Unicode string representation of object \var{o}. Returns the
1519 Unicode string representation on success, \NULL{} on failure. This is
1520 the equivalent of the Python expression \samp{unistr(\var{o})}.
1521 Called by the \function{unistr()}\bifuncindex{unistr} built-in function.
1524 \begin{cfuncdesc}{int}{PyObject_IsInstance}{PyObject *inst, PyObject *cls}
1525 Return \code{1} if \var{inst} is an instance of the class \var{cls} or
1526 a subclass of \var{cls}. If \var{cls} is a type object rather than a
1527 class object, \cfunction{PyObject_IsInstance()} returns \code{1} if
1528 \var{inst} is of type \var{cls}. If \var{inst} is not a class
1529 instance and \var{cls} is neither a type object or class object,
1530 \var{inst} must have a \member{__class__} attribute --- the class
1531 relationship of the value of that attribute with \var{cls} will be
1532 used to determine the result of this function.
1536 Subclass determination is done in a fairly straightforward way, but
1537 includes a wrinkle that implementors of extensions to the class system
1538 may want to be aware of. If \class{A} and \class{B} are class
1539 objects, \class{B} is a subclass of \class{A} if it inherits from
1540 \class{A} either directly or indirectly. If either is not a class
1541 object, a more general mechanism is used to determine the class
1542 relationship of the two objects. When testing if \var{B} is a
1543 subclass of \var{A}, if \var{A} is \var{B},
1544 \cfunction{PyObject_IsSubclass()} returns true. If \var{A} and
1545 \var{B} are different objects, \var{B}'s \member{__bases__} attribute
1546 is searched in a depth-first fashion for \var{A} --- the presence of
1547 the \member{__bases__} attribute is considered sufficient for this
1550 \begin{cfuncdesc}{int}{PyObject_IsSubclass}{PyObject *derived,
1552 Returns \code{1} if the class \var{derived} is identical to or derived
1553 from the class \var{cls}, otherwise returns \code{0}. In case of an
1554 error, returns \code{-1}. If either \var{derived} or \var{cls} is not
1555 an actual class object, this function uses the generic algorithm
1561 \begin{cfuncdesc}{int}{PyCallable_Check}{PyObject *o}
1562 Determine if the object \var{o} is callable. Return \code{1} if the
1563 object is callable and \code{0} otherwise.
1564 This function always succeeds.
1568 \begin{cfuncdesc}{PyObject*}{PyObject_CallObject}{PyObject *callable_object,
1570 Call a callable Python object \var{callable_object}, with
1571 arguments given by the tuple \var{args}. If no arguments are
1572 needed, then \var{args} may be \NULL{}. Returns the result of the
1573 call on success, or \NULL{} on failure. This is the equivalent
1574 of the Python expression \samp{apply(\var{callable_object}, \var{args})}.
1578 \begin{cfuncdesc}{PyObject*}{PyObject_CallFunction}{PyObject *callable_object,
1580 Call a callable Python object \var{callable_object}, with a
1581 variable number of C arguments. The C arguments are described
1582 using a \cfunction{Py_BuildValue()} style format string. The format may
1583 be \NULL{}, indicating that no arguments are provided. Returns the
1584 result of the call on success, or \NULL{} on failure. This is
1585 the equivalent of the Python expression \samp{apply(\var{callable_object},
1586 \var{args})}.\bifuncindex{apply}
1590 \begin{cfuncdesc}{PyObject*}{PyObject_CallMethod}{PyObject *o,
1591 char *method, char *format, ...}
1592 Call the method named \var{m} of object \var{o} with a variable number
1593 of C arguments. The C arguments are described by a
1594 \cfunction{Py_BuildValue()} format string. The format may be \NULL{},
1595 indicating that no arguments are provided. Returns the result of the
1596 call on success, or \NULL{} on failure. This is the equivalent of the
1597 Python expression \samp{\var{o}.\var{method}(\var{args})}.
1598 Note that special method names, such as \method{__add__()},
1599 \method{__getitem__()}, and so on are not supported. The specific
1600 abstract-object routines for these must be used.
1604 \begin{cfuncdesc}{int}{PyObject_Hash}{PyObject *o}
1605 Compute and return the hash value of an object \var{o}. On
1606 failure, return \code{-1}. This is the equivalent of the Python
1607 expression \samp{hash(\var{o})}.\bifuncindex{hash}
1611 \begin{cfuncdesc}{int}{PyObject_IsTrue}{PyObject *o}
1612 Returns \code{1} if the object \var{o} is considered to be true, and
1613 \code{0} otherwise. This is equivalent to the Python expression
1614 \samp{not not \var{o}}.
1615 This function always succeeds.
1619 \begin{cfuncdesc}{PyObject*}{PyObject_Type}{PyObject *o}
1620 On success, returns a type object corresponding to the object
1621 type of object \var{o}. On failure, returns \NULL{}. This is
1622 equivalent to the Python expression \samp{type(\var{o})}.
1626 \begin{cfuncdesc}{int}{PyObject_Length}{PyObject *o}
1627 Return the length of object \var{o}. If the object \var{o} provides
1628 both sequence and mapping protocols, the sequence length is
1629 returned. On error, \code{-1} is returned. This is the equivalent
1630 to the Python expression \samp{len(\var{o})}.\bifuncindex{len}
1634 \begin{cfuncdesc}{PyObject*}{PyObject_GetItem}{PyObject *o, PyObject *key}
1635 Return element of \var{o} corresponding to the object \var{key} or
1636 \NULL{} on failure. This is the equivalent of the Python expression
1637 \samp{\var{o}[\var{key}]}.
1641 \begin{cfuncdesc}{int}{PyObject_SetItem}{PyObject *o, PyObject *key, PyObject *v}
1642 Map the object \var{key} to the value \var{v}.
1643 Returns \code{-1} on failure. This is the equivalent
1644 of the Python statement \samp{\var{o}[\var{key}] = \var{v}}.
1648 \begin{cfuncdesc}{int}{PyObject_DelItem}{PyObject *o, PyObject *key}
1649 Delete the mapping for \var{key} from \var{o}. Returns \code{-1} on
1650 failure. This is the equivalent of the Python statement \samp{del
1651 \var{o}[\var{key}]}.
1654 \begin{cfuncdesc}{int}{PyObject_AsFileDescriptor}{PyObject *o}
1655 Derives a file-descriptor from a Python object. If the object
1656 is an integer or long integer, its value is returned. If not, the
1657 object's \method{fileno()} method is called if it exists; the method
1658 must return an integer or long integer, which is returned as the file
1659 descriptor value. Returns \code{-1} on failure.
1662 \section{Number Protocol \label{number}}
1664 \begin{cfuncdesc}{int}{PyNumber_Check}{PyObject *o}
1665 Returns \code{1} if the object \var{o} provides numeric protocols, and
1667 This function always succeeds.
1671 \begin{cfuncdesc}{PyObject*}{PyNumber_Add}{PyObject *o1, PyObject *o2}
1672 Returns the result of adding \var{o1} and \var{o2}, or \NULL{} on
1673 failure. This is the equivalent of the Python expression
1674 \samp{\var{o1} + \var{o2}}.
1678 \begin{cfuncdesc}{PyObject*}{PyNumber_Subtract}{PyObject *o1, PyObject *o2}
1679 Returns the result of subtracting \var{o2} from \var{o1}, or
1680 \NULL{} on failure. This is the equivalent of the Python expression
1681 \samp{\var{o1} - \var{o2}}.
1685 \begin{cfuncdesc}{PyObject*}{PyNumber_Multiply}{PyObject *o1, PyObject *o2}
1686 Returns the result of multiplying \var{o1} and \var{o2}, or \NULL{} on
1687 failure. This is the equivalent of the Python expression
1688 \samp{\var{o1} * \var{o2}}.
1692 \begin{cfuncdesc}{PyObject*}{PyNumber_Divide}{PyObject *o1, PyObject *o2}
1693 Returns the result of dividing \var{o1} by \var{o2}, or \NULL{} on
1695 This is the equivalent of the Python expression \samp{\var{o1} /
1700 \begin{cfuncdesc}{PyObject*}{PyNumber_Remainder}{PyObject *o1, PyObject *o2}
1701 Returns the remainder of dividing \var{o1} by \var{o2}, or \NULL{} on
1702 failure. This is the equivalent of the Python expression
1703 \samp{\var{o1} \%\ \var{o2}}.
1707 \begin{cfuncdesc}{PyObject*}{PyNumber_Divmod}{PyObject *o1, PyObject *o2}
1708 See the built-in function \function{divmod()}\bifuncindex{divmod}.
1709 Returns \NULL{} on failure. This is the equivalent of the Python
1710 expression \samp{divmod(\var{o1}, \var{o2})}.
1714 \begin{cfuncdesc}{PyObject*}{PyNumber_Power}{PyObject *o1, PyObject *o2, PyObject *o3}
1715 See the built-in function \function{pow()}\bifuncindex{pow}. Returns
1716 \NULL{} on failure. This is the equivalent of the Python expression
1717 \samp{pow(\var{o1}, \var{o2}, \var{o3})}, where \var{o3} is optional.
1718 If \var{o3} is to be ignored, pass \cdata{Py_None} in its place
1719 (passing \NULL{} for \var{o3} would cause an illegal memory access).
1723 \begin{cfuncdesc}{PyObject*}{PyNumber_Negative}{PyObject *o}
1724 Returns the negation of \var{o} on success, or \NULL{} on failure.
1725 This is the equivalent of the Python expression \samp{-\var{o}}.
1729 \begin{cfuncdesc}{PyObject*}{PyNumber_Positive}{PyObject *o}
1730 Returns \var{o} on success, or \NULL{} on failure.
1731 This is the equivalent of the Python expression \samp{+\var{o}}.
1735 \begin{cfuncdesc}{PyObject*}{PyNumber_Absolute}{PyObject *o}
1736 Returns the absolute value of \var{o}, or \NULL{} on failure. This is
1737 the equivalent of the Python expression \samp{abs(\var{o})}.
1742 \begin{cfuncdesc}{PyObject*}{PyNumber_Invert}{PyObject *o}
1743 Returns the bitwise negation of \var{o} on success, or \NULL{} on
1744 failure. This is the equivalent of the Python expression
1749 \begin{cfuncdesc}{PyObject*}{PyNumber_Lshift}{PyObject *o1, PyObject *o2}
1750 Returns the result of left shifting \var{o1} by \var{o2} on success,
1751 or \NULL{} on failure. This is the equivalent of the Python
1752 expression \samp{\var{o1} <\code{<} \var{o2}}.
1756 \begin{cfuncdesc}{PyObject*}{PyNumber_Rshift}{PyObject *o1, PyObject *o2}
1757 Returns the result of right shifting \var{o1} by \var{o2} on success,
1758 or \NULL{} on failure. This is the equivalent of the Python
1759 expression \samp{\var{o1} >\code{>} \var{o2}}.
1763 \begin{cfuncdesc}{PyObject*}{PyNumber_And}{PyObject *o1, PyObject *o2}
1764 Returns the ``bitwise and'' of \var{o2} and \var{o2} on success and
1765 \NULL{} on failure. This is the equivalent of the Python expression
1766 \samp{\var{o1} \&\ \var{o2}}.
1770 \begin{cfuncdesc}{PyObject*}{PyNumber_Xor}{PyObject *o1, PyObject *o2}
1771 Returns the ``bitwise exclusive or'' of \var{o1} by \var{o2} on success,
1772 or \NULL{} on failure. This is the equivalent of the Python
1773 expression \samp{\var{o1} \textasciicircum{} \var{o2}}.
1776 \begin{cfuncdesc}{PyObject*}{PyNumber_Or}{PyObject *o1, PyObject *o2}
1777 Returns the ``bitwise or'' of \var{o1} and \var{o2} on success, or
1778 \NULL{} on failure. This is the equivalent of the Python expression
1779 \samp{\var{o1} | \var{o2}}.
1783 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceAdd}{PyObject *o1, PyObject *o2}
1784 Returns the result of adding \var{o1} and \var{o2}, or \NULL{} on failure.
1785 The operation is done \emph{in-place} when \var{o1} supports it. This is the
1786 equivalent of the Python expression \samp{\var{o1} += \var{o2}}.
1790 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceSubtract}{PyObject *o1, PyObject *o2}
1791 Returns the result of subtracting \var{o2} from \var{o1}, or
1792 \NULL{} on failure. The operation is done \emph{in-place} when \var{o1}
1793 supports it. This is the equivalent of the Python expression \samp{\var{o1}
1798 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceMultiply}{PyObject *o1, PyObject *o2}
1799 Returns the result of multiplying \var{o1} and \var{o2}, or \NULL{} on
1800 failure. The operation is done \emph{in-place} when \var{o1} supports it.
1801 This is the equivalent of the Python expression \samp{\var{o1} *= \var{o2}}.
1805 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceDivide}{PyObject *o1, PyObject *o2}
1806 Returns the result of dividing \var{o1} by \var{o2}, or \NULL{} on failure.
1807 The operation is done \emph{in-place} when \var{o1} supports it. This is the
1808 equivalent of the Python expression \samp{\var{o1} /= \var{o2}}.
1812 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceRemainder}{PyObject *o1, PyObject *o2}
1813 Returns the remainder of dividing \var{o1} by \var{o2}, or \NULL{} on
1814 failure. The operation is done \emph{in-place} when \var{o1} supports it.
1815 This is the equivalent of the Python expression \samp{\var{o1} \%= \var{o2}}.
1819 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlacePower}{PyObject *o1, PyObject *o2, PyObject *o3}
1820 See the built-in function \function{pow()}\bifuncindex{pow}. Returns
1821 \NULL{} on failure. The operation is done \emph{in-place} when \var{o1}
1822 supports it. This is the equivalent of the Python expression \samp{\var{o1}
1823 **= \var{o2}} when o3 is \cdata{Py_None}, or an in-place variant of
1824 \samp{pow(\var{o1}, \var{o2}, \var{o3})} otherwise. If \var{o3} is to be
1825 ignored, pass \cdata{Py_None} in its place (passing \NULL{} for \var{o3}
1826 would cause an illegal memory access).
1829 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceLshift}{PyObject *o1, PyObject *o2}
1830 Returns the result of left shifting \var{o1} by \var{o2} on success, or
1831 \NULL{} on failure. The operation is done \emph{in-place} when \var{o1}
1832 supports it. This is the equivalent of the Python expression \samp{\var{o1}
1833 <\code{<=} \var{o2}}.
1837 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceRshift}{PyObject *o1, PyObject *o2}
1838 Returns the result of right shifting \var{o1} by \var{o2} on success, or
1839 \NULL{} on failure. The operation is done \emph{in-place} when \var{o1}
1840 supports it. This is the equivalent of the Python expression \samp{\var{o1}
1841 >\code{>=} \var{o2}}.
1845 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceAnd}{PyObject *o1, PyObject *o2}
1846 Returns the ``bitwise and'' of \var{o1} and \var{o2} on success
1847 and \NULL{} on failure. The operation is done \emph{in-place} when
1848 \var{o1} supports it. This is the equivalent of the Python expression
1849 \samp{\var{o1} \&= \var{o2}}.
1853 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceXor}{PyObject *o1, PyObject *o2}
1854 Returns the ``bitwise exclusive or'' of \var{o1} by \var{o2} on success, or
1855 \NULL{} on failure. The operation is done \emph{in-place} when \var{o1}
1856 supports it. This is the equivalent of the Python expression \samp{\var{o1}
1857 \textasciicircum= \var{o2}}.
1860 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceOr}{PyObject *o1, PyObject *o2}
1861 Returns the ``bitwise or'' of \var{o1} and \var{o2} on success, or \NULL{}
1862 on failure. The operation is done \emph{in-place} when \var{o1} supports
1863 it. This is the equivalent of the Python expression \samp{\var{o1} |=
1867 \begin{cfuncdesc}{int}{PyNumber_Coerce}{PyObject **p1, PyObject **p2}
1868 This function takes the addresses of two variables of type
1869 \ctype{PyObject*}. If the objects pointed to by \code{*\var{p1}} and
1870 \code{*\var{p2}} have the same type, increment their reference count
1871 and return \code{0} (success). If the objects can be converted to a
1872 common numeric type, replace \code{*p1} and \code{*p2} by their
1873 converted value (with 'new' reference counts), and return \code{0}.
1874 If no conversion is possible, or if some other error occurs, return
1875 \code{-1} (failure) and don't increment the reference counts. The
1876 call \code{PyNumber_Coerce(\&o1, \&o2)} is equivalent to the Python
1877 statement \samp{\var{o1}, \var{o2} = coerce(\var{o1}, \var{o2})}.
1878 \bifuncindex{coerce}
1881 \begin{cfuncdesc}{PyObject*}{PyNumber_Int}{PyObject *o}
1882 Returns the \var{o} converted to an integer object on success, or
1883 \NULL{} on failure. This is the equivalent of the Python
1884 expression \samp{int(\var{o})}.\bifuncindex{int}
1887 \begin{cfuncdesc}{PyObject*}{PyNumber_Long}{PyObject *o}
1888 Returns the \var{o} converted to a long integer object on success,
1889 or \NULL{} on failure. This is the equivalent of the Python
1890 expression \samp{long(\var{o})}.\bifuncindex{long}
1893 \begin{cfuncdesc}{PyObject*}{PyNumber_Float}{PyObject *o}
1894 Returns the \var{o} converted to a float object on success, or
1895 \NULL{} on failure. This is the equivalent of the Python expression
1896 \samp{float(\var{o})}.\bifuncindex{float}
1900 \section{Sequence Protocol \label{sequence}}
1902 \begin{cfuncdesc}{int}{PySequence_Check}{PyObject *o}
1903 Return \code{1} if the object provides sequence protocol, and
1904 \code{0} otherwise. This function always succeeds.
1907 \begin{cfuncdesc}{int}{PySequence_Size}{PyObject *o}
1908 Returns the number of objects in sequence \var{o} on success, and
1909 \code{-1} on failure. For objects that do not provide sequence
1910 protocol, this is equivalent to the Python expression
1911 \samp{len(\var{o})}.\bifuncindex{len}
1914 \begin{cfuncdesc}{int}{PySequence_Length}{PyObject *o}
1915 Alternate name for \cfunction{PySequence_Size()}.
1918 \begin{cfuncdesc}{PyObject*}{PySequence_Concat}{PyObject *o1, PyObject *o2}
1919 Return the concatenation of \var{o1} and \var{o2} on success, and \NULL{} on
1920 failure. This is the equivalent of the Python
1921 expression \samp{\var{o1} + \var{o2}}.
1925 \begin{cfuncdesc}{PyObject*}{PySequence_Repeat}{PyObject *o, int count}
1926 Return the result of repeating sequence object
1927 \var{o} \var{count} times, or \NULL{} on failure. This is the
1928 equivalent of the Python expression \samp{\var{o} * \var{count}}.
1931 \begin{cfuncdesc}{PyObject*}{PySequence_InPlaceConcat}{PyObject *o1, PyObject *o2}
1932 Return the concatenation of \var{o1} and \var{o2} on success, and \NULL{} on
1933 failure. The operation is done \emph{in-place} when \var{o1} supports it.
1934 This is the equivalent of the Python expression \samp{\var{o1} += \var{o2}}.
1938 \begin{cfuncdesc}{PyObject*}{PySequence_InPlaceRepeat}{PyObject *o, int count}
1939 Return the result of repeating sequence object \var{o} \var{count} times, or
1940 \NULL{} on failure. The operation is done \emph{in-place} when \var{o}
1941 supports it. This is the equivalent of the Python expression \samp{\var{o}
1946 \begin{cfuncdesc}{PyObject*}{PySequence_GetItem}{PyObject *o, int i}
1947 Return the \var{i}th element of \var{o}, or \NULL{} on failure. This
1948 is the equivalent of the Python expression \samp{\var{o}[\var{i}]}.
1952 \begin{cfuncdesc}{PyObject*}{PySequence_GetSlice}{PyObject *o, int i1, int i2}
1953 Return the slice of sequence object \var{o} between \var{i1} and
1954 \var{i2}, or \NULL{} on failure. This is the equivalent of the Python
1955 expression \samp{\var{o}[\var{i1}:\var{i2}]}.
1959 \begin{cfuncdesc}{int}{PySequence_SetItem}{PyObject *o, int i, PyObject *v}
1960 Assign object \var{v} to the \var{i}th element of \var{o}.
1961 Returns \code{-1} on failure. This is the equivalent of the Python
1962 statement \samp{\var{o}[\var{i}] = \var{v}}.
1965 \begin{cfuncdesc}{int}{PySequence_DelItem}{PyObject *o, int i}
1966 Delete the \var{i}th element of object \var{o}. Returns
1967 \code{-1} on failure. This is the equivalent of the Python
1968 statement \samp{del \var{o}[\var{i}]}.
1971 \begin{cfuncdesc}{int}{PySequence_SetSlice}{PyObject *o, int i1,
1972 int i2, PyObject *v}
1973 Assign the sequence object \var{v} to the slice in sequence
1974 object \var{o} from \var{i1} to \var{i2}. This is the equivalent of
1975 the Python statement \samp{\var{o}[\var{i1}:\var{i2}] = \var{v}}.
1978 \begin{cfuncdesc}{int}{PySequence_DelSlice}{PyObject *o, int i1, int i2}
1979 Delete the slice in sequence object \var{o} from \var{i1} to \var{i2}.
1980 Returns \code{-1} on failure. This is the equivalent of the Python
1981 statement \samp{del \var{o}[\var{i1}:\var{i2}]}.
1984 \begin{cfuncdesc}{PyObject*}{PySequence_Tuple}{PyObject *o}
1985 Returns the \var{o} as a tuple on success, and \NULL{} on failure.
1986 This is equivalent to the Python expression \samp{tuple(\var{o})}.
1990 \begin{cfuncdesc}{int}{PySequence_Count}{PyObject *o, PyObject *value}
1991 Return the number of occurrences of \var{value} in \var{o}, that is,
1992 return the number of keys for which \code{\var{o}[\var{key}] ==
1993 \var{value}}. On failure, return \code{-1}. This is equivalent to
1994 the Python expression \samp{\var{o}.count(\var{value})}.
1997 \begin{cfuncdesc}{int}{PySequence_Contains}{PyObject *o, PyObject *value}
1998 Determine if \var{o} contains \var{value}. If an item in \var{o} is
1999 equal to \var{value}, return \code{1}, otherwise return \code{0}. On
2000 error, return \code{-1}. This is equivalent to the Python expression
2001 \samp{\var{value} in \var{o}}.
2004 \begin{cfuncdesc}{int}{PySequence_Index}{PyObject *o, PyObject *value}
2005 Return the first index \var{i} for which \code{\var{o}[\var{i}] ==
2006 \var{value}}. On error, return \code{-1}. This is equivalent to
2007 the Python expression \samp{\var{o}.index(\var{value})}.
2010 \begin{cfuncdesc}{PyObject*}{PySequence_List}{PyObject *o}
2011 Return a list object with the same contents as the arbitrary sequence
2012 \var{o}. The returned list is guaranteed to be new.
2015 \begin{cfuncdesc}{PyObject*}{PySequence_Tuple}{PyObject *o}
2016 Return a tuple object with the same contents as the arbitrary sequence
2017 \var{o}. If \var{o} is a tuple, a new reference will be returned,
2018 otherwise a tuple will be constructed with the appropriate contents.
2022 \begin{cfuncdesc}{PyObject*}{PySequence_Fast}{PyObject *o, const char *m}
2023 Returns the sequence \var{o} as a tuple, unless it is already a
2024 tuple or list, in which case \var{o} is returned. Use
2025 \cfunction{PySequence_Fast_GET_ITEM()} to access the members of the
2026 result. Returns \NULL{} on failure. If the object is not a sequence,
2027 raises \exception{TypeError} with \var{m} as the message text.
2030 \begin{cfuncdesc}{PyObject*}{PySequence_Fast_GET_ITEM}{PyObject *o, int i}
2031 Return the \var{i}th element of \var{o}, assuming that \var{o} was
2032 returned by \cfunction{PySequence_Fast()}, and that \var{i} is within
2033 bounds. The caller is expected to get the length of the sequence by
2034 calling \cfunction{PySequence_Size()} on \var{o}, since lists and tuples
2035 are guaranteed to always return their true length.
2039 \section{Mapping Protocol \label{mapping}}
2041 \begin{cfuncdesc}{int}{PyMapping_Check}{PyObject *o}
2042 Return \code{1} if the object provides mapping protocol, and
2043 \code{0} otherwise. This function always succeeds.
2047 \begin{cfuncdesc}{int}{PyMapping_Length}{PyObject *o}
2048 Returns the number of keys in object \var{o} on success, and
2049 \code{-1} on failure. For objects that do not provide mapping
2050 protocol, this is equivalent to the Python expression
2051 \samp{len(\var{o})}.\bifuncindex{len}
2055 \begin{cfuncdesc}{int}{PyMapping_DelItemString}{PyObject *o, char *key}
2056 Remove the mapping for object \var{key} from the object \var{o}.
2057 Return \code{-1} on failure. This is equivalent to
2058 the Python statement \samp{del \var{o}[\var{key}]}.
2062 \begin{cfuncdesc}{int}{PyMapping_DelItem}{PyObject *o, PyObject *key}
2063 Remove the mapping for object \var{key} from the object \var{o}.
2064 Return \code{-1} on failure. This is equivalent to
2065 the Python statement \samp{del \var{o}[\var{key}]}.
2069 \begin{cfuncdesc}{int}{PyMapping_HasKeyString}{PyObject *o, char *key}
2070 On success, return \code{1} if the mapping object has the key
2071 \var{key} and \code{0} otherwise. This is equivalent to the Python
2072 expression \samp{\var{o}.has_key(\var{key})}.
2073 This function always succeeds.
2077 \begin{cfuncdesc}{int}{PyMapping_HasKey}{PyObject *o, PyObject *key}
2078 Return \code{1} if the mapping object has the key \var{key} and
2079 \code{0} otherwise. This is equivalent to the Python expression
2080 \samp{\var{o}.has_key(\var{key})}.
2081 This function always succeeds.
2085 \begin{cfuncdesc}{PyObject*}{PyMapping_Keys}{PyObject *o}
2086 On success, return a list of the keys in object \var{o}. On
2087 failure, return \NULL{}. This is equivalent to the Python
2088 expression \samp{\var{o}.keys()}.
2092 \begin{cfuncdesc}{PyObject*}{PyMapping_Values}{PyObject *o}
2093 On success, return a list of the values in object \var{o}. On
2094 failure, return \NULL{}. This is equivalent to the Python
2095 expression \samp{\var{o}.values()}.
2099 \begin{cfuncdesc}{PyObject*}{PyMapping_Items}{PyObject *o}
2100 On success, return a list of the items in object \var{o}, where
2101 each item is a tuple containing a key-value pair. On
2102 failure, return \NULL{}. This is equivalent to the Python
2103 expression \samp{\var{o}.items()}.
2107 \begin{cfuncdesc}{PyObject*}{PyMapping_GetItemString}{PyObject *o, char *key}
2108 Return element of \var{o} corresponding to the object \var{key} or
2109 \NULL{} on failure. This is the equivalent of the Python expression
2110 \samp{\var{o}[\var{key}]}.
2113 \begin{cfuncdesc}{int}{PyMapping_SetItemString}{PyObject *o, char *key, PyObject *v}
2114 Map the object \var{key} to the value \var{v} in object \var{o}.
2115 Returns \code{-1} on failure. This is the equivalent of the Python
2116 statement \samp{\var{o}[\var{key}] = \var{v}}.
2120 \chapter{Concrete Objects Layer \label{concrete}}
2122 The functions in this chapter are specific to certain Python object
2123 types. Passing them an object of the wrong type is not a good idea;
2124 if you receive an object from a Python program and you are not sure
2125 that it has the right type, you must perform a type check first;
2126 for example, to check that an object is a dictionary, use
2127 \cfunction{PyDict_Check()}. The chapter is structured like the
2128 ``family tree'' of Python object types.
2131 While the functions described in this chapter carefully check the type
2132 of the objects which are passed in, many of them do not check for
2133 \NULL{} being passed instead of a valid object. Allowing \NULL{} to
2134 be passed in can cause memory access violations and immediate
2135 termination of the interpreter.
2138 \section{Fundamental Objects \label{fundamental}}
2140 This section describes Python type objects and the singleton object
2144 \subsection{Type Objects \label{typeObjects}}
2147 \begin{ctypedesc}{PyTypeObject}
2148 The C structure of the objects used to describe built-in types.
2151 \begin{cvardesc}{PyObject*}{PyType_Type}
2152 This is the type object for type objects; it is the same object as
2153 \code{types.TypeType} in the Python layer.
2154 \withsubitem{(in module types)}{\ttindex{TypeType}}
2157 \begin{cfuncdesc}{int}{PyType_Check}{PyObject *o}
2158 Returns true is the object \var{o} is a type object.
2161 \begin{cfuncdesc}{int}{PyType_HasFeature}{PyObject *o, int feature}
2162 Returns true if the type object \var{o} sets the feature
2163 \var{feature}. Type features are denoted by single bit flags.
2167 \subsection{The None Object \label{noneObject}}
2169 \obindex{None@\texttt{None}}
2170 Note that the \ctype{PyTypeObject} for \code{None} is not directly
2171 exposed in the Python/C API. Since \code{None} is a singleton,
2172 testing for object identity (using \samp{==} in C) is sufficient.
2173 There is no \cfunction{PyNone_Check()} function for the same reason.
2175 \begin{cvardesc}{PyObject*}{Py_None}
2176 The Python \code{None} object, denoting lack of value. This object has
2181 \section{Numeric Objects \label{numericObjects}}
2186 \subsection{Plain Integer Objects \label{intObjects}}
2189 \begin{ctypedesc}{PyIntObject}
2190 This subtype of \ctype{PyObject} represents a Python integer object.
2193 \begin{cvardesc}{PyTypeObject}{PyInt_Type}
2194 This instance of \ctype{PyTypeObject} represents the Python plain
2195 integer type. This is the same object as \code{types.IntType}.
2196 \withsubitem{(in modules types)}{\ttindex{IntType}}
2199 \begin{cfuncdesc}{int}{PyInt_Check}{PyObject* o}
2200 Returns true if \var{o} is of type \cdata{PyInt_Type}.
2203 \begin{cfuncdesc}{PyObject*}{PyInt_FromLong}{long ival}
2204 Creates a new integer object with a value of \var{ival}.
2206 The current implementation keeps an array of integer objects for all
2207 integers between \code{-1} and \code{100}, when you create an int in
2208 that range you actually just get back a reference to the existing
2209 object. So it should be possible to change the value of \code{1}. I
2210 suspect the behaviour of Python in this case is undefined. :-)
2213 \begin{cfuncdesc}{long}{PyInt_AsLong}{PyObject *io}
2214 Will first attempt to cast the object to a \ctype{PyIntObject}, if
2215 it is not already one, and then return its value.
2218 \begin{cfuncdesc}{long}{PyInt_AS_LONG}{PyObject *io}
2219 Returns the value of the object \var{io}. No error checking is
2223 \begin{cfuncdesc}{long}{PyInt_GetMax}{}
2224 Returns the system's idea of the largest integer it can handle
2225 (\constant{LONG_MAX}\ttindex{LONG_MAX}, as defined in the system
2230 \subsection{Long Integer Objects \label{longObjects}}
2232 \obindex{long integer}
2233 \begin{ctypedesc}{PyLongObject}
2234 This subtype of \ctype{PyObject} represents a Python long integer
2238 \begin{cvardesc}{PyTypeObject}{PyLong_Type}
2239 This instance of \ctype{PyTypeObject} represents the Python long
2240 integer type. This is the same object as \code{types.LongType}.
2241 \withsubitem{(in modules types)}{\ttindex{LongType}}
2244 \begin{cfuncdesc}{int}{PyLong_Check}{PyObject *p}
2245 Returns true if its argument is a \ctype{PyLongObject}.
2248 \begin{cfuncdesc}{PyObject*}{PyLong_FromLong}{long v}
2249 Returns a new \ctype{PyLongObject} object from \var{v}, or \NULL{} on
2253 \begin{cfuncdesc}{PyObject*}{PyLong_FromUnsignedLong}{unsigned long v}
2254 Returns a new \ctype{PyLongObject} object from a C \ctype{unsigned
2255 long}, or \NULL{} on failure.
2258 \begin{cfuncdesc}{PyObject*}{PyLong_FromDouble}{double v}
2259 Returns a new \ctype{PyLongObject} object from the integer part of
2260 \var{v}, or \NULL{} on failure.
2263 \begin{cfuncdesc}{long}{PyLong_AsLong}{PyObject *pylong}
2264 Returns a C \ctype{long} representation of the contents of
2265 \var{pylong}. If \var{pylong} is greater than
2266 \constant{LONG_MAX}\ttindex{LONG_MAX}, an \exception{OverflowError} is
2267 raised.\withsubitem{(built-in exception)}{\ttindex{OverflowError}}
2270 \begin{cfuncdesc}{unsigned long}{PyLong_AsUnsignedLong}{PyObject *pylong}
2271 Returns a C \ctype{unsigned long} representation of the contents of
2272 \var{pylong}. If \var{pylong} is greater than
2273 \constant{ULONG_MAX}\ttindex{ULONG_MAX}, an \exception{OverflowError}
2274 is raised.\withsubitem{(built-in exception)}{\ttindex{OverflowError}}
2277 \begin{cfuncdesc}{double}{PyLong_AsDouble}{PyObject *pylong}
2278 Returns a C \ctype{double} representation of the contents of \var{pylong}.
2281 \begin{cfuncdesc}{PyObject*}{PyLong_FromString}{char *str, char **pend,
2283 Return a new \ctype{PyLongObject} based on the string value in
2284 \var{str}, which is interpreted according to the radix in \var{base}.
2285 If \var{pend} is non-\NULL, \code{*\var{pend}} will point to the first
2286 character in \var{str} which follows the representation of the
2287 number. If \var{base} is \code{0}, the radix will be determined base
2288 on the leading characters of \var{str}: if \var{str} starts with
2289 \code{'0x'} or \code{'0X'}, radix 16 will be used; if \var{str} starts
2290 with \code{'0'}, radix 8 will be used; otherwise radix 10 will be
2291 used. If \var{base} is not \code{0}, it must be between \code{2} and
2292 \code{36}, inclusive. Leading spaces are ignored. If there are no
2293 digits, \exception{ValueError} will be raised.
2297 \subsection{Floating Point Objects \label{floatObjects}}
2299 \obindex{floating point}
2300 \begin{ctypedesc}{PyFloatObject}
2301 This subtype of \ctype{PyObject} represents a Python floating point
2305 \begin{cvardesc}{PyTypeObject}{PyFloat_Type}
2306 This instance of \ctype{PyTypeObject} represents the Python floating
2307 point type. This is the same object as \code{types.FloatType}.
2308 \withsubitem{(in modules types)}{\ttindex{FloatType}}
2311 \begin{cfuncdesc}{int}{PyFloat_Check}{PyObject *p}
2312 Returns true if its argument is a \ctype{PyFloatObject}.
2315 \begin{cfuncdesc}{PyObject*}{PyFloat_FromDouble}{double v}
2316 Creates a \ctype{PyFloatObject} object from \var{v}, or \NULL{} on
2320 \begin{cfuncdesc}{double}{PyFloat_AsDouble}{PyObject *pyfloat}
2321 Returns a C \ctype{double} representation of the contents of \var{pyfloat}.
2324 \begin{cfuncdesc}{double}{PyFloat_AS_DOUBLE}{PyObject *pyfloat}
2325 Returns a C \ctype{double} representation of the contents of
2326 \var{pyfloat}, but without error checking.
2330 \subsection{Complex Number Objects \label{complexObjects}}
2332 \obindex{complex number}
2333 Python's complex number objects are implemented as two distinct types
2334 when viewed from the C API: one is the Python object exposed to
2335 Python programs, and the other is a C structure which represents the
2336 actual complex number value. The API provides functions for working
2339 \subsubsection{Complex Numbers as C Structures}
2341 Note that the functions which accept these structures as parameters
2342 and return them as results do so \emph{by value} rather than
2343 dereferencing them through pointers. This is consistent throughout
2346 \begin{ctypedesc}{Py_complex}
2347 The C structure which corresponds to the value portion of a Python
2348 complex number object. Most of the functions for dealing with complex
2349 number objects use structures of this type as input or output values,
2350 as appropriate. It is defined as:
2360 \begin{cfuncdesc}{Py_complex}{_Py_c_sum}{Py_complex left, Py_complex right}
2361 Return the sum of two complex numbers, using the C
2362 \ctype{Py_complex} representation.
2365 \begin{cfuncdesc}{Py_complex}{_Py_c_diff}{Py_complex left, Py_complex right}
2366 Return the difference between two complex numbers, using the C
2367 \ctype{Py_complex} representation.
2370 \begin{cfuncdesc}{Py_complex}{_Py_c_neg}{Py_complex complex}
2371 Return the negation of the complex number \var{complex}, using the C
2372 \ctype{Py_complex} representation.
2375 \begin{cfuncdesc}{Py_complex}{_Py_c_prod}{Py_complex left, Py_complex right}
2376 Return the product of two complex numbers, using the C
2377 \ctype{Py_complex} representation.
2380 \begin{cfuncdesc}{Py_complex}{_Py_c_quot}{Py_complex dividend,
2382 Return the quotient of two complex numbers, using the C
2383 \ctype{Py_complex} representation.
2386 \begin{cfuncdesc}{Py_complex}{_Py_c_pow}{Py_complex num, Py_complex exp}
2387 Return the exponentiation of \var{num} by \var{exp}, using the C
2388 \ctype{Py_complex} representation.
2392 \subsubsection{Complex Numbers as Python Objects}
2394 \begin{ctypedesc}{PyComplexObject}
2395 This subtype of \ctype{PyObject} represents a Python complex number object.
2398 \begin{cvardesc}{PyTypeObject}{PyComplex_Type}
2399 This instance of \ctype{PyTypeObject} represents the Python complex
2403 \begin{cfuncdesc}{int}{PyComplex_Check}{PyObject *p}
2404 Returns true if its argument is a \ctype{PyComplexObject}.
2407 \begin{cfuncdesc}{PyObject*}{PyComplex_FromCComplex}{Py_complex v}
2408 Create a new Python complex number object from a C
2409 \ctype{Py_complex} value.
2412 \begin{cfuncdesc}{PyObject*}{PyComplex_FromDoubles}{double real, double imag}
2413 Returns a new \ctype{PyComplexObject} object from \var{real} and \var{imag}.
2416 \begin{cfuncdesc}{double}{PyComplex_RealAsDouble}{PyObject *op}
2417 Returns the real part of \var{op} as a C \ctype{double}.
2420 \begin{cfuncdesc}{double}{PyComplex_ImagAsDouble}{PyObject *op}
2421 Returns the imaginary part of \var{op} as a C \ctype{double}.
2424 \begin{cfuncdesc}{Py_complex}{PyComplex_AsCComplex}{PyObject *op}
2425 Returns the \ctype{Py_complex} value of the complex number \var{op}.
2430 \section{Sequence Objects \label{sequenceObjects}}
2433 Generic operations on sequence objects were discussed in the previous
2434 chapter; this section deals with the specific kinds of sequence
2435 objects that are intrinsic to the Python language.
2438 \subsection{String Objects \label{stringObjects}}
2440 These functions raise \exception{TypeError} when expecting a string
2441 parameter and are called with a non-string parameter.
2444 \begin{ctypedesc}{PyStringObject}
2445 This subtype of \ctype{PyObject} represents a Python string object.
2448 \begin{cvardesc}{PyTypeObject}{PyString_Type}
2449 This instance of \ctype{PyTypeObject} represents the Python string
2450 type; it is the same object as \code{types.TypeType} in the Python
2451 layer.\withsubitem{(in module types)}{\ttindex{StringType}}.
2454 \begin{cfuncdesc}{int}{PyString_Check}{PyObject *o}
2455 Returns true if the object \var{o} is a string object.
2458 \begin{cfuncdesc}{PyObject*}{PyString_FromString}{const char *v}
2459 Returns a new string object with the value \var{v} on success, and
2460 \NULL{} on failure. The parameter \var{v} must not be \NULL; it
2461 will not be checked.
2464 \begin{cfuncdesc}{PyObject*}{PyString_FromStringAndSize}{const char *v,
2466 Returns a new string object with the value \var{v} and length
2467 \var{len} on success, and \NULL{} on failure. If \var{v} is \NULL{},
2468 the contents of the string are uninitialized.
2471 \begin{cfuncdesc}{int}{PyString_Size}{PyObject *string}
2472 Returns the length of the string in string object \var{string}.
2475 \begin{cfuncdesc}{int}{PyString_GET_SIZE}{PyObject *string}
2476 Macro form of \cfunction{PyString_Size()} but without error
2480 \begin{cfuncdesc}{char*}{PyString_AsString}{PyObject *string}
2481 Returns a null-terminated representation of the contents of
2482 \var{string}. The pointer refers to the internal buffer of
2483 \var{string}, not a copy. The data must not be modified in any way,
2484 unless the string was just created using
2485 \code{PyString_FromStringAndSize(NULL, \var{size})}.
2486 It must not be deallocated.
2489 \begin{cfuncdesc}{char*}{PyString_AS_STRING}{PyObject *string}
2490 Macro form of \cfunction{PyString_AsString()} but without error
2494 \begin{cfuncdesc}{int}{PyString_AsStringAndSize}{PyObject *obj,
2497 Returns a null-terminated representation of the contents of the object
2498 \var{obj} through the output variables \var{buffer} and \var{length}.
2500 The function accepts both string and Unicode objects as input. For
2501 Unicode objects it returns the default encoded version of the object.
2502 If \var{length} is set to \NULL{}, the resulting buffer may not contain
2503 null characters; if it does, the function returns -1 and a
2504 TypeError is raised.
2506 The buffer refers to an internal string buffer of \var{obj}, not a
2507 copy. The data must not be modified in any way, unless the string was
2508 just created using \code{PyString_FromStringAndSize(NULL,
2509 \var{size})}. It must not be deallocated.
2512 \begin{cfuncdesc}{void}{PyString_Concat}{PyObject **string,
2514 Creates a new string object in \var{*string} containing the
2515 contents of \var{newpart} appended to \var{string}; the caller will
2516 own the new reference. The reference to the old value of \var{string}
2517 will be stolen. If the new string
2518 cannot be created, the old reference to \var{string} will still be
2519 discarded and the value of \var{*string} will be set to
2520 \NULL{}; the appropriate exception will be set.
2523 \begin{cfuncdesc}{void}{PyString_ConcatAndDel}{PyObject **string,
2525 Creates a new string object in \var{*string} containing the contents
2526 of \var{newpart} appended to \var{string}. This version decrements
2527 the reference count of \var{newpart}.
2530 \begin{cfuncdesc}{int}{_PyString_Resize}{PyObject **string, int newsize}
2531 A way to resize a string object even though it is ``immutable''.
2532 Only use this to build up a brand new string object; don't use this if
2533 the string may already be known in other parts of the code.
2536 \begin{cfuncdesc}{PyObject*}{PyString_Format}{PyObject *format,
2538 Returns a new string object from \var{format} and \var{args}. Analogous
2539 to \code{\var{format} \%\ \var{args}}. The \var{args} argument must be
2543 \begin{cfuncdesc}{void}{PyString_InternInPlace}{PyObject **string}
2544 Intern the argument \var{*string} in place. The argument must be the
2545 address of a pointer variable pointing to a Python string object.
2546 If there is an existing interned string that is the same as
2547 \var{*string}, it sets \var{*string} to it (decrementing the reference
2548 count of the old string object and incrementing the reference count of
2549 the interned string object), otherwise it leaves \var{*string} alone
2550 and interns it (incrementing its reference count). (Clarification:
2551 even though there is a lot of talk about reference counts, think of
2552 this function as reference-count-neutral; you own the object after
2553 the call if and only if you owned it before the call.)
2556 \begin{cfuncdesc}{PyObject*}{PyString_InternFromString}{const char *v}
2557 A combination of \cfunction{PyString_FromString()} and
2558 \cfunction{PyString_InternInPlace()}, returning either a new string object
2559 that has been interned, or a new (``owned'') reference to an earlier
2560 interned string object with the same value.
2563 \begin{cfuncdesc}{PyObject*}{PyString_Decode}{const char *s,
2565 const char *encoding,
2567 Create a string object by decoding \var{size} bytes of the encoded
2568 buffer \var{s}. \var{encoding} and \var{errors} have the same meaning
2569 as the parameters of the same name in the unicode() builtin
2570 function. The codec to be used is looked up using the Python codec
2571 registry. Returns \NULL{} in case an exception was raised by the
2575 \begin{cfuncdesc}{PyObject*}{PyString_Encode}{const Py_UNICODE *s,
2577 const char *encoding,
2579 Encodes the \ctype{Py_UNICODE} buffer of the given size and returns a
2580 Python string object. \var{encoding} and \var{errors} have the same
2581 meaning as the parameters of the same name in the string .encode()
2582 method. The codec to be used is looked up using the Python codec
2583 registry. Returns \NULL{} in case an exception was raised by the
2587 \begin{cfuncdesc}{PyObject*}{PyString_AsEncodedString}{PyObject *unicode,
2588 const char *encoding,
2590 Encodes a string object and returns the result as Python string
2591 object. \var{encoding} and \var{errors} have the same meaning as the
2592 parameters of the same name in the string .encode() method. The codec
2593 to be used is looked up using the Python codec registry. Returns
2594 \NULL{} in case an exception was raised by the codec.
2598 \subsection{Unicode Objects \label{unicodeObjects}}
2599 \sectionauthor{Marc-Andre Lemburg}{mal@lemburg.com}
2601 %--- Unicode Type -------------------------------------------------------
2603 These are the basic Unicode object types used for the Unicode
2604 implementation in Python:
2606 \begin{ctypedesc}{Py_UNICODE}
2607 This type represents a 16-bit unsigned storage type which is used by
2608 Python internally as basis for holding Unicode ordinals. On platforms
2609 where \ctype{wchar_t} is available and also has 16-bits,
2610 \ctype{Py_UNICODE} is a typedef alias for \ctype{wchar_t} to enhance
2611 native platform compatibility. On all other platforms,
2612 \ctype{Py_UNICODE} is a typedef alias for \ctype{unsigned short}.
2615 \begin{ctypedesc}{PyUnicodeObject}
2616 This subtype of \ctype{PyObject} represents a Python Unicode object.
2619 \begin{cvardesc}{PyTypeObject}{PyUnicode_Type}
2620 This instance of \ctype{PyTypeObject} represents the Python Unicode type.
2623 %--- These are really C macros... is there a macrodesc TeX macro ?
2625 The following APIs are really C macros and can be used to do fast
2626 checks and to access internal read-only data of Unicode objects:
2628 \begin{cfuncdesc}{int}{PyUnicode_Check}{PyObject *o}
2629 Returns true if the object \var{o} is a Unicode object.
2632 \begin{cfuncdesc}{int}{PyUnicode_GET_SIZE}{PyObject *o}
2633 Returns the size of the object. o has to be a
2634 PyUnicodeObject (not checked).
2637 \begin{cfuncdesc}{int}{PyUnicode_GET_DATA_SIZE}{PyObject *o}
2638 Returns the size of the object's internal buffer in bytes. o has to be
2639 a PyUnicodeObject (not checked).
2642 \begin{cfuncdesc}{Py_UNICODE*}{PyUnicode_AS_UNICODE}{PyObject *o}
2643 Returns a pointer to the internal Py_UNICODE buffer of the object. o
2644 has to be a PyUnicodeObject (not checked).
2647 \begin{cfuncdesc}{const char*}{PyUnicode_AS_DATA}{PyObject *o}
2648 Returns a (const char *) pointer to the internal buffer of the object.
2649 o has to be a PyUnicodeObject (not checked).
2652 % --- Unicode character properties ---------------------------------------
2654 Unicode provides many different character properties. The most often
2655 needed ones are available through these macros which are mapped to C
2656 functions depending on the Python configuration.
2658 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISSPACE
}{Py_UNICODE ch
}
2659 Returns
1/
0 depending on whether
\var{ch
} is a whitespace character.
2662 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISLOWER
}{Py_UNICODE ch
}
2663 Returns
1/
0 depending on whether
\var{ch
} is a lowercase character.
2666 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISUPPER
}{Py_UNICODE ch
}
2667 Returns
1/
0 depending on whether
\var{ch
} is an uppercase character.
2670 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISTITLE
}{Py_UNICODE ch
}
2671 Returns
1/
0 depending on whether
\var{ch
} is a titlecase character.
2674 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISLINEBREAK
}{Py_UNICODE ch
}
2675 Returns
1/
0 depending on whether
\var{ch
} is a linebreak character.
2678 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISDECIMAL
}{Py_UNICODE ch
}
2679 Returns
1/
0 depending on whether
\var{ch
} is a decimal character.
2682 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISDIGIT
}{Py_UNICODE ch
}
2683 Returns
1/
0 depending on whether
\var{ch
} is a digit character.
2686 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISNUMERIC
}{Py_UNICODE ch
}
2687 Returns
1/
0 depending on whether
\var{ch
} is a numeric character.
2690 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISALPHA
}{Py_UNICODE ch
}
2691 Returns
1/
0 depending on whether
\var{ch
} is an alphabetic character.
2694 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISALNUM
}{Py_UNICODE ch
}
2695 Returns
1/
0 depending on whether
\var{ch
} is an alphanumeric character.
2698 These APIs can be used for fast direct character conversions:
2700 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOLOWER
}{Py_UNICODE ch
}
2701 Returns the character
\var{ch
} converted to lower case.
2704 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOUPPER
}{Py_UNICODE ch
}
2705 Returns the character
\var{ch
} converted to upper case.
2708 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOTITLE
}{Py_UNICODE ch
}
2709 Returns the character
\var{ch
} converted to title case.
2712 \begin{cfuncdesc
}{int
}{Py_UNICODE_TODECIMAL
}{Py_UNICODE ch
}
2713 Returns the character
\var{ch
} converted to a decimal positive integer.
2714 Returns -
1 in case this is not possible. Does not raise exceptions.
2717 \begin{cfuncdesc
}{int
}{Py_UNICODE_TODIGIT
}{Py_UNICODE ch
}
2718 Returns the character
\var{ch
} converted to a single digit integer.
2719 Returns -
1 in case this is not possible. Does not raise exceptions.
2722 \begin{cfuncdesc
}{double
}{Py_UNICODE_TONUMERIC
}{Py_UNICODE ch
}
2723 Returns the character
\var{ch
} converted to a (positive) double.
2724 Returns -
1.0 in case this is not possible. Does not raise exceptions.
2727 % --- Plain Py_UNICODE ---------------------------------------------------
2729 To create Unicode objects and access their basic sequence properties,
2732 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromUnicode
}{const Py_UNICODE *u,
2735 Create a Unicode Object from the Py_UNICODE buffer
\var{u
} of the
2736 given size.
\var{u
} may be
\NULL{} which causes the contents to be
2737 undefined. It is the user's responsibility to fill in the needed data.
2738 The buffer is copied into the new object.
2741 \begin{cfuncdesc
}{Py_UNICODE*
}{PyUnicode_AsUnicode
}{PyObject *unicode
}
2742 Return a read-only pointer to the Unicode object's internal
2743 \ctype{Py_UNICODE
} buffer.
2746 \begin{cfuncdesc
}{int
}{PyUnicode_GetSize
}{PyObject *unicode
}
2747 Return the length of the Unicode object.
2750 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromEncodedObject
}{PyObject *obj,
2751 const char *encoding,
2754 Coerce an encoded object obj to an Unicode object and return a
2755 reference with incremented refcount.
2757 Coercion is done in the following way:
2759 \item Unicode objects are passed back as-is with incremented
2760 refcount. Note: these cannot be decoded; passing a non-NULL
2761 value for encoding will result in a TypeError.
2763 \item String and other char buffer compatible objects are decoded
2764 according to the given encoding and using the error handling
2765 defined by errors. Both can be NULL to have the interface use
2766 the default values (see the next section for details).
2768 \item All other objects cause an exception.
2770 The API returns NULL in case of an error. The caller is responsible
2771 for decref'ing the returned objects.
2774 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromObject
}{PyObject *obj
}
2776 Shortcut for PyUnicode_FromEncodedObject(obj, NULL, ``strict'')
2777 which is used throughout the interpreter whenever coercion to
2781 % --- wchar_t support for platforms which support it ---------------------
2783 If the platform supports
\ctype{wchar_t
} and provides a header file
2784 wchar.h, Python can interface directly to this type using the
2785 following functions. Support is optimized if Python's own
2786 \ctype{Py_UNICODE
} type is identical to the system's
\ctype{wchar_t
}.
2788 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromWideChar
}{const wchar_t *w,
2790 Create a Unicode Object from the
\ctype{whcar_t
} buffer
\var{w
} of the
2791 given size. Returns
\NULL{} on failure.
2794 \begin{cfuncdesc
}{int
}{PyUnicode_AsWideChar
}{PyUnicodeObject *unicode,
2797 Copies the Unicode Object contents into the
\ctype{whcar_t
} buffer
2798 \var{w
}. At most
\var{size
} \ctype{whcar_t
} characters are copied.
2799 Returns the number of
\ctype{whcar_t
} characters copied or -
1 in case
2804 \subsubsection{Builtin Codecs
\label{builtinCodecs
}}
2806 Python provides a set of builtin codecs which are written in C
2807 for speed. All of these codecs are directly usable via the
2808 following functions.
2810 Many of the following APIs take two arguments encoding and
2811 errors. These parameters encoding and errors have the same semantics
2812 as the ones of the builtin unicode() Unicode object constructor.
2814 Setting encoding to NULL causes the default encoding to be used which
2817 Error handling is set by errors which may also be set to NULL meaning
2818 to use the default handling defined for the codec. Default error
2819 handling for all builtin codecs is ``strict'' (ValueErrors are raised).
2821 The codecs all use a similar interface. Only deviation from the
2822 following generic ones are documented for simplicity.
2824 % --- Generic Codecs -----------------------------------------------------
2826 These are the generic codec APIs:
2828 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Decode
}{const char *s,
2830 const char *encoding,
2832 Create a Unicode object by decoding
\var{size
} bytes of the encoded
2833 string
\var{s
}.
\var{encoding
} and
\var{errors
} have the same meaning
2834 as the parameters of the same name in the unicode() builtin
2835 function. The codec to be used is looked up using the Python codec
2836 registry. Returns
\NULL{} in case an exception was raised by the
2840 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Encode
}{const Py_UNICODE *s,
2842 const char *encoding,
2844 Encodes the
\ctype{Py_UNICODE
} buffer of the given size and returns a
2845 Python string object.
\var{encoding
} and
\var{errors
} have the same
2846 meaning as the parameters of the same name in the Unicode .encode()
2847 method. The codec to be used is looked up using the Python codec
2848 registry. Returns
\NULL{} in case an exception was raised by the
2852 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsEncodedString
}{PyObject *unicode,
2853 const char *encoding,
2855 Encodes a Unicode object and returns the result as Python string
2856 object.
\var{encoding
} and
\var{errors
} have the same meaning as the
2857 parameters of the same name in the Unicode .encode() method. The codec
2858 to be used is looked up using the Python codec registry. Returns
2859 \NULL{} in case an exception was raised by the codec.
2862 % --- UTF-8 Codecs -------------------------------------------------------
2864 These are the UTF-
8 codec APIs:
2866 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUTF8
}{const char *s,
2869 Creates a Unicode object by decoding
\var{size
} bytes of the UTF-
8
2870 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
2871 raised by the codec.
2874 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUTF8
}{const Py_UNICODE *s,
2877 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using UTF-
8
2878 and returns a Python string object. Returns
\NULL{} in case an
2879 exception was raised by the codec.
2882 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUTF8String
}{PyObject *unicode
}
2883 Encodes a Unicode objects using UTF-
8 and returns the result as Python
2884 string object. Error handling is ``strict''. Returns
2885 \NULL{} in case an exception was raised by the codec.
2888 % --- UTF-16 Codecs ------------------------------------------------------ */
2890 These are the UTF-
16 codec APIs:
2892 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUTF16
}{const char *s,
2896 Decodes
\var{length
} bytes from a UTF-
16 encoded buffer string and
2897 returns the corresponding Unicode object.
2899 \var{errors
} (if non-NULL) defines the error handling. It defaults
2902 If
\var{byteorder
} is non-
\NULL{}, the decoder starts decoding using
2903 the given byte order:
2906 *byteorder == -
1: little endian
2907 *byteorder ==
0: native order
2908 *byteorder ==
1: big endian
2911 and then switches according to all byte order marks (BOM) it finds in
2912 the input data. BOM marks are not copied into the resulting Unicode
2913 string. After completion,
\var{*byteorder
} is set to the current byte
2914 order at the end of input data.
2916 If
\var{byteorder
} is
\NULL{}, the codec starts in native order mode.
2918 Returns
\NULL{} in case an exception was raised by the codec.
2921 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUTF16
}{const Py_UNICODE *s,
2925 Returns a Python string object holding the UTF-
16 encoded value of the
2926 Unicode data in
\var{s
}.
2928 If
\var{byteorder
} is not
\code{0}, output is written according to the
2929 following byte order:
2932 byteorder == -
1: little endian
2933 byteorder ==
0: native byte order (writes a BOM mark)
2934 byteorder ==
1: big endian
2937 If byteorder is
\code{0}, the output string will always start with the
2938 Unicode BOM mark (U+FEFF). In the other two modes, no BOM mark is
2941 Note that
\ctype{Py_UNICODE
} data is being interpreted as UTF-
16
2942 reduced to UCS-
2. This trick makes it possible to add full UTF-
16
2943 capabilities at a later point without comprimising the APIs.
2945 Returns
\NULL{} in case an exception was raised by the codec.
2948 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUTF16String
}{PyObject *unicode
}
2949 Returns a Python string using the UTF-
16 encoding in native byte
2950 order. The string always starts with a BOM mark. Error handling is
2951 ``strict''. Returns
\NULL{} in case an exception was raised by the
2955 % --- Unicode-Escape Codecs ----------------------------------------------
2957 These are the ``Unicode Esacpe'' codec APIs:
2959 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUnicodeEscape
}{const char *s,
2962 Creates a Unicode object by decoding
\var{size
} bytes of the Unicode-Esacpe
2963 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
2964 raised by the codec.
2967 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUnicodeEscape
}{const Py_UNICODE *s,
2970 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Unicode-Escape
2971 and returns a Python string object. Returns
\NULL{} in case an
2972 exception was raised by the codec.
2975 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUnicodeEscapeString
}{PyObject *unicode
}
2976 Encodes a Unicode objects using Unicode-Escape and returns the result
2977 as Python string object. Error handling is ``strict''. Returns
2978 \NULL{} in case an exception was raised by the codec.
2981 % --- Raw-Unicode-Escape Codecs ------------------------------------------
2983 These are the ``Raw Unicode Esacpe'' codec APIs:
2985 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeRawUnicodeEscape
}{const char *s,
2988 Creates a Unicode object by decoding
\var{size
} bytes of the Raw-Unicode-Esacpe
2989 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
2990 raised by the codec.
2993 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeRawUnicodeEscape
}{const Py_UNICODE *s,
2996 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Raw-Unicode-Escape
2997 and returns a Python string object. Returns
\NULL{} in case an
2998 exception was raised by the codec.
3001 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsRawUnicodeEscapeString
}{PyObject *unicode
}
3002 Encodes a Unicode objects using Raw-Unicode-Escape and returns the result
3003 as Python string object. Error handling is ``strict''. Returns
3004 \NULL{} in case an exception was raised by the codec.
3007 % --- Latin-1 Codecs -----------------------------------------------------
3009 These are the Latin-
1 codec APIs:
3011 Latin-
1 corresponds to the first
256 Unicode ordinals and only these
3012 are accepted by the codecs during encoding.
3014 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeLatin1
}{const char *s,
3017 Creates a Unicode object by decoding
\var{size
} bytes of the Latin-
1
3018 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3019 raised by the codec.
3022 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeLatin1
}{const Py_UNICODE *s,
3025 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Latin-
1
3026 and returns a Python string object. Returns
\NULL{} in case an
3027 exception was raised by the codec.
3030 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsLatin1String
}{PyObject *unicode
}
3031 Encodes a Unicode objects using Latin-
1 and returns the result as
3032 Python string object. Error handling is ``strict''. Returns
3033 \NULL{} in case an exception was raised by the codec.
3036 % --- ASCII Codecs -------------------------------------------------------
3038 These are the
\ASCII{} codec APIs. Only
7-bit
\ASCII{} data is
3039 accepted. All other codes generate errors.
3041 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeASCII
}{const char *s,
3044 Creates a Unicode object by decoding
\var{size
} bytes of the
3045 \ASCII{} encoded string
\var{s
}. Returns
\NULL{} in case an exception
3046 was raised by the codec.
3049 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeASCII
}{const Py_UNICODE *s,
3052 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using
3053 \ASCII{} and returns a Python string object. Returns
\NULL{} in case
3054 an exception was raised by the codec.
3057 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsASCIIString
}{PyObject *unicode
}
3058 Encodes a Unicode objects using
\ASCII{} and returns the result as Python
3059 string object. Error handling is ``strict''. Returns
3060 \NULL{} in case an exception was raised by the codec.
3063 % --- Character Map Codecs -----------------------------------------------
3065 These are the mapping codec APIs:
3067 This codec is special in that it can be used to implement many
3068 different codecs (and this is in fact what was done to obtain most of
3069 the standard codecs included in the
\module{encodings
} package). The
3070 codec uses mapping to encode and decode characters.
3072 Decoding mappings must map single string characters to single Unicode
3073 characters, integers (which are then interpreted as Unicode ordinals)
3074 or None (meaning "undefined mapping" and causing an error).
3076 Encoding mappings must map single Unicode characters to single string
3077 characters, integers (which are then interpreted as Latin-
1 ordinals)
3078 or None (meaning "undefined mapping" and causing an error).
3080 The mapping objects provided must only support the __getitem__ mapping
3083 If a character lookup fails with a LookupError, the character is
3084 copied as-is meaning that its ordinal value will be interpreted as
3085 Unicode or Latin-
1 ordinal resp. Because of this, mappings only need
3086 to contain those mappings which map characters to different code
3089 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeCharmap
}{const char *s,
3093 Creates a Unicode object by decoding
\var{size
} bytes of the encoded
3094 string
\var{s
} using the given
\var{mapping
} object. Returns
\NULL{}
3095 in case an exception was raised by the codec.
3098 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeCharmap
}{const Py_UNICODE *s,
3102 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using the
3103 given
\var{mapping
} object and returns a Python string object.
3104 Returns
\NULL{} in case an exception was raised by the codec.
3107 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsCharmapString
}{PyObject *unicode,
3109 Encodes a Unicode objects using the given
\var{mapping
} object and
3110 returns the result as Python string object. Error handling is
3111 ``strict''. Returns
\NULL{} in case an exception was raised by the
3115 The following codec API is special in that maps Unicode to Unicode.
3117 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_TranslateCharmap
}{const Py_UNICODE *s,
3121 Translates a
\ctype{Py_UNICODE
} buffer of the given length by applying
3122 a character mapping
\var{table
} to it and returns the resulting
3123 Unicode object. Returns
\NULL{} when an exception was raised by the
3126 The
\var{mapping
} table must map Unicode ordinal integers to Unicode
3127 ordinal integers or None (causing deletion of the character).
3129 Mapping tables must only provide the __getitem__ interface,
3130 e.g. dictionaries or sequences. Unmapped character ordinals (ones
3131 which cause a LookupError) are left untouched and are copied as-is.
3134 % --- MBCS codecs for Windows --------------------------------------------
3136 These are the MBCS codec APIs. They are currently only available on
3137 Windows and use the Win32 MBCS converters to implement the
3138 conversions. Note that MBCS (or DBCS) is a class of encodings, not
3139 just one. The target encoding is defined by the user settings on the
3140 machine running the codec.
3142 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeMBCS
}{const char *s,
3145 Creates a Unicode object by decoding
\var{size
} bytes of the MBCS
3146 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3147 raised by the codec.
3150 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeMBCS
}{const Py_UNICODE *s,
3153 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using MBCS
3154 and returns a Python string object. Returns
\NULL{} in case an
3155 exception was raised by the codec.
3158 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsMBCSString
}{PyObject *unicode
}
3159 Encodes a Unicode objects using MBCS and returns the result as Python
3160 string object. Error handling is ``strict''. Returns
\NULL{} in case
3161 an exception was raised by the codec.
3164 % --- Methods & Slots ----------------------------------------------------
3166 \subsubsection{Methods and Slot Functions
\label{unicodeMethodsAndSlots
}}
3168 The following APIs are capable of handling Unicode objects and strings
3169 on input (we refer to them as strings in the descriptions) and return
3170 Unicode objects or integers as apporpriate.
3172 They all return
\NULL{} or -
1 in case an exception occurrs.
3174 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Concat
}{PyObject *left,
3176 Concat two strings giving a new Unicode string.
3179 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Split
}{PyObject *s,
3182 Split a string giving a list of Unicode strings.
3184 If sep is NULL, splitting will be done at all whitespace
3185 substrings. Otherwise, splits occur at the given separator.
3187 At most maxsplit splits will be done. If negative, no limit is set.
3189 Separators are not included in the resulting list.
3192 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Splitlines
}{PyObject *s,
3194 Split a Unicode string at line breaks, returning a list of Unicode
3195 strings. CRLF is considered to be one line break. The Line break
3196 characters are not included in the resulting strings.
3199 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Translate
}{PyObject *str,
3202 Translate a string by applying a character mapping table to it and
3203 return the resulting Unicode object.
3205 The mapping table must map Unicode ordinal integers to Unicode ordinal
3206 integers or None (causing deletion of the character).
3208 Mapping tables must only provide the __getitem__ interface,
3209 e.g. dictionaries or sequences. Unmapped character ordinals (ones
3210 which cause a LookupError) are left untouched and are copied as-is.
3212 \var{errors
} has the usual meaning for codecs. It may be
\NULL{}
3213 which indicates to use the default error handling.
3216 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Join
}{PyObject *separator,
3218 Join a sequence of strings using the given separator and return
3219 the resulting Unicode string.
3222 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Tailmatch
}{PyObject *str,
3227 Return
1 if
\var{substr
} matches
\var{str
}[\var{start
}:
\var{end
}] at
3228 the given tail end (
\var{direction
} == -
1 means to do a prefix match,
3229 \var{direction
} ==
1 a suffix match),
0 otherwise.
3232 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Find
}{PyObject *str,
3237 Return the first position of
\var{substr
} in
3238 \var{str
}[\var{start
}:
\var{end
}] using the given
\var{direction
}
3239 (
\var{direction
} ==
1 means to do a forward search,
3240 \var{direction
} == -
1 a backward search),
0 otherwise.
3243 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Count
}{PyObject *str,
3247 Count the number of occurrences of
\var{substr
} in
3248 \var{str
}[\var{start
}:
\var{end
}]
3251 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Replace
}{PyObject *str,
3255 Replace at most
\var{maxcount
} occurrences of
\var{substr
} in
3256 \var{str
} with
\var{replstr
} and return the resulting Unicode object.
3257 \var{maxcount
} == -
1 means: replace all occurrences.
3260 \begin{cfuncdesc
}{int
}{PyUnicode_Compare
}{PyObject *left, PyObject *right
}
3261 Compare two strings and return -
1,
0,
1 for less than, equal,
3265 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Format
}{PyObject *format,
3267 Returns a new string object from
\var{format
} and
\var{args
}; this is
3268 analogous to
\code{\var{format
} \%\
\var{args
}}. The
3269 \var{args
} argument must be a tuple.
3272 \begin{cfuncdesc
}{int
}{PyUnicode_Contains
}{PyObject *container,
3274 Checks whether
\var{element
} is contained in
\var{container
} and
3275 returns true or false accordingly.
3277 \var{element
} has to coerce to a one element Unicode string.
\code{-
1} is
3278 returned in case of an error.
3282 \subsection{Buffer Objects
\label{bufferObjects
}}
3283 \sectionauthor{Greg Stein
}{gstein@lyra.org
}
3286 Python objects implemented in C can export a group of functions called
3287 the ``buffer
\index{buffer interface
} interface.'' These functions can
3288 be used by an object to expose its data in a raw, byte-oriented
3289 format. Clients of the object can use the buffer interface to access
3290 the object data directly, without needing to copy it first.
3292 Two examples of objects that support
3293 the buffer interface are strings and arrays. The string object exposes
3294 the character contents in the buffer interface's byte-oriented
3295 form. An array can also expose its contents, but it should be noted
3296 that array elements may be multi-byte values.
3298 An example user of the buffer interface is the file object's
3299 \method{write()
} method. Any object that can export a series of bytes
3300 through the buffer interface can be written to a file. There are a
3301 number of format codes to
\cfunction{PyArgs_ParseTuple()
} that operate
3302 against an object's buffer interface, returning data from the target
3305 More information on the buffer interface is provided in the section
3306 ``Buffer Object Structures'' (section
\ref{buffer-structs
}), under
3307 the description for
\ctype{PyBufferProcs
}\ttindex{PyBufferProcs
}.
3309 A ``buffer object'' is defined in the
\file{bufferobject.h
} header
3310 (included by
\file{Python.h
}). These objects look very similar to
3311 string objects at the Python programming level: they support slicing,
3312 indexing, concatenation, and some other standard string
3313 operations. However, their data can come from one of two sources: from
3314 a block of memory, or from another object which exports the buffer
3317 Buffer objects are useful as a way to expose the data from another
3318 object's buffer interface to the Python programmer. They can also be
3319 used as a zero-copy slicing mechanism. Using their ability to
3320 reference a block of memory, it is possible to expose any data to the
3321 Python programmer quite easily. The memory could be a large, constant
3322 array in a C extension, it could be a raw block of memory for
3323 manipulation before passing to an operating system library, or it
3324 could be used to pass around structured data in its native, in-memory
3327 \begin{ctypedesc
}{PyBufferObject
}
3328 This subtype of
\ctype{PyObject
} represents a buffer object.
3331 \begin{cvardesc
}{PyTypeObject
}{PyBuffer_Type
}
3332 The instance of
\ctype{PyTypeObject
} which represents the Python
3333 buffer type; it is the same object as
\code{types.BufferType
} in the
3334 Python layer.
\withsubitem{(in module types)
}{\ttindex{BufferType
}}.
3337 \begin{cvardesc
}{int
}{Py_END_OF_BUFFER
}
3338 This constant may be passed as the
\var{size
} parameter to
3339 \cfunction{PyBuffer_FromObject()
} or
3340 \cfunction{PyBuffer_FromReadWriteObject()
}. It indicates that the new
3341 \ctype{PyBufferObject
} should refer to
\var{base
} object from the
3342 specified
\var{offset
} to the end of its exported buffer. Using this
3343 enables the caller to avoid querying the
\var{base
} object for its
3347 \begin{cfuncdesc
}{int
}{PyBuffer_Check
}{PyObject *p
}
3348 Return true if the argument has type
\cdata{PyBuffer_Type
}.
3351 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromObject
}{PyObject *base,
3352 int offset, int size
}
3353 Return a new read-only buffer object. This raises
3354 \exception{TypeError
} if
\var{base
} doesn't support the read-only
3355 buffer protocol or doesn't provide exactly one buffer segment, or it
3356 raises
\exception{ValueError
} if
\var{offset
} is less than zero. The
3357 buffer will hold a reference to the
\var{base
} object, and the
3358 buffer's contents will refer to the
\var{base
} object's buffer
3359 interface, starting as position
\var{offset
} and extending for
3360 \var{size
} bytes. If
\var{size
} is
\constant{Py_END_OF_BUFFER
}, then
3361 the new buffer's contents extend to the length of the
3362 \var{base
} object's exported buffer data.
3365 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromReadWriteObject
}{PyObject *base,
3368 Return a new writable buffer object. Parameters and exceptions are
3369 similar to those for
\cfunction{PyBuffer_FromObject()
}.
3370 If the
\var{base
} object does not export the writeable buffer
3371 protocol, then
\exception{TypeError
} is raised.
3374 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromMemory
}{void *ptr, int size
}
3375 Return a new read-only buffer object that reads from a specified
3376 location in memory, with a specified size.
3377 The caller is responsible for ensuring that the memory buffer, passed
3378 in as
\var{ptr
}, is not deallocated while the returned buffer object
3379 exists. Raises
\exception{ValueError
} if
\var{size
} is less than
3380 zero. Note that
\constant{Py_END_OF_BUFFER
} may
\emph{not
} be passed
3381 for the
\var{size
} parameter;
\exception{ValueError
} will be raised in
3385 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromReadWriteMemory
}{void *ptr, int size
}
3386 Similar to
\cfunction{PyBuffer_FromMemory()
}, but the returned buffer
3390 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_New
}{int size
}
3391 Returns a new writable buffer object that maintains its own memory
3392 buffer of
\var{size
} bytes.
\exception{ValueError
} is returned if
3393 \var{size
} is not zero or positive.
3397 \subsection{Tuple Objects
\label{tupleObjects
}}
3400 \begin{ctypedesc
}{PyTupleObject
}
3401 This subtype of
\ctype{PyObject
} represents a Python tuple object.
3404 \begin{cvardesc
}{PyTypeObject
}{PyTuple_Type
}
3405 This instance of
\ctype{PyTypeObject
} represents the Python tuple
3406 type; it is the same object as
\code{types.TupleType
} in the Python
3407 layer.
\withsubitem{(in module types)
}{\ttindex{TupleType
}}.
3410 \begin{cfuncdesc
}{int
}{PyTuple_Check
}{PyObject *p
}
3411 Return true if the argument is a tuple object.
3414 \begin{cfuncdesc
}{PyObject*
}{PyTuple_New
}{int len
}
3415 Return a new tuple object of size
\var{len
}, or
\NULL{} on failure.
3418 \begin{cfuncdesc
}{int
}{PyTuple_Size
}{PyObject *p
}
3419 Takes a pointer to a tuple object, and returns the size
3423 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GetItem
}{PyObject *p, int pos
}
3424 Returns the object at position
\var{pos
} in the tuple pointed
3425 to by
\var{p
}. If
\var{pos
} is out of bounds, returns
\NULL{} and
3426 sets an
\exception{IndexError
} exception.
3429 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GET_ITEM
}{PyObject *p, int pos
}
3430 Does the same, but does no checking of its arguments.
3433 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GetSlice
}{PyObject *p,
3435 Takes a slice of the tuple pointed to by
\var{p
} from
3436 \var{low
} to
\var{high
} and returns it as a new tuple.
3439 \begin{cfuncdesc
}{int
}{PyTuple_SetItem
}{PyObject *p,
3440 int pos, PyObject *o
}
3441 Inserts a reference to object
\var{o
} at position
\var{pos
} of
3442 the tuple pointed to by
\var{p
}. It returns
\code{0} on success.
3443 \strong{Note:
} This function ``steals'' a reference to
\var{o
}.
3446 \begin{cfuncdesc
}{void
}{PyTuple_SET_ITEM
}{PyObject *p,
3447 int pos, PyObject *o
}
3448 Does the same, but does no error checking, and
3449 should
\emph{only
} be used to fill in brand new tuples.
3450 \strong{Note:
} This function ``steals'' a reference to
\var{o
}.
3453 \begin{cfuncdesc
}{int
}{_PyTuple_Resize
}{PyObject **p,
3454 int newsize, int last_is_sticky
}
3455 Can be used to resize a tuple.
\var{newsize
} will be the new length
3456 of the tuple. Because tuples are
\emph{supposed
} to be immutable,
3457 this should only be used if there is only one reference to the object.
3458 Do
\emph{not
} use this if the tuple may already be known to some other
3459 part of the code. The tuple will always grow or shrink at the end. The
3460 \var{last_is_sticky
} flag is not used and should always be false. Think
3461 of this as destroying the old tuple and creating a new one, only more
3462 efficiently. Returns
\code{0} on success and
\code{-
1} on failure (in
3463 which case a
\exception{MemoryError
} or
\exception{SystemError
} will be
3468 \subsection{List Objects
\label{listObjects
}}
3471 \begin{ctypedesc
}{PyListObject
}
3472 This subtype of
\ctype{PyObject
} represents a Python list object.
3475 \begin{cvardesc
}{PyTypeObject
}{PyList_Type
}
3476 This instance of
\ctype{PyTypeObject
} represents the Python list
3477 type. This is the same object as
\code{types.ListType
}.
3478 \withsubitem{(in module types)
}{\ttindex{ListType
}}
3481 \begin{cfuncdesc
}{int
}{PyList_Check
}{PyObject *p
}
3482 Returns true if its argument is a
\ctype{PyListObject
}.
3485 \begin{cfuncdesc
}{PyObject*
}{PyList_New
}{int len
}
3486 Returns a new list of length
\var{len
} on success, or
\NULL{} on
3490 \begin{cfuncdesc
}{int
}{PyList_Size
}{PyObject *list
}
3491 Returns the length of the list object in
\var{list
}; this is
3492 equivalent to
\samp{len(
\var{list
})
} on a list object.
3496 \begin{cfuncdesc
}{int
}{PyList_GET_SIZE
}{PyObject *list
}
3497 Macro form of
\cfunction{PyList_Size()
} without error checking.
3500 \begin{cfuncdesc
}{PyObject*
}{PyList_GetItem
}{PyObject *list, int index
}
3501 Returns the object at position
\var{pos
} in the list pointed
3502 to by
\var{p
}. If
\var{pos
} is out of bounds, returns
\NULL{} and
3503 sets an
\exception{IndexError
} exception.
3506 \begin{cfuncdesc
}{PyObject*
}{PyList_GET_ITEM
}{PyObject *list, int i
}
3507 Macro form of
\cfunction{PyList_GetItem()
} without error checking.
3510 \begin{cfuncdesc
}{int
}{PyList_SetItem
}{PyObject *list, int index,
3512 Sets the item at index
\var{index
} in list to
\var{item
}.
3513 Returns
\code{0} on success or
\code{-
1} on failure.
3514 \strong{Note:
} This function ``steals'' a reference to
\var{item
} and
3515 discards a reference to an item already in the list at the affected
3519 \begin{cfuncdesc
}{void
}{PyList_SET_ITEM
}{PyObject *list, int i,
3521 Macro form of
\cfunction{PyList_SetItem()
} without error checking.
3522 \strong{Note:
} This function ``steals'' a reference to
\var{item
},
3523 and, unlike
\cfunction{PyList_SetItem()
}, does
\emph{not
} discard a
3524 reference to any item that it being replaced; any reference in
3525 \var{list
} at position
\var{i
} will be leaked. This is normally only
3526 used to fill in new lists where there is no previous content.
3529 \begin{cfuncdesc
}{int
}{PyList_Insert
}{PyObject *list, int index,
3531 Inserts the item
\var{item
} into list
\var{list
} in front of index
3532 \var{index
}. Returns
\code{0} if successful; returns
\code{-
1} and
3533 raises an exception if unsuccessful. Analogous to
3534 \code{\var{list
}.insert(
\var{index
},
\var{item
})
}.
3537 \begin{cfuncdesc
}{int
}{PyList_Append
}{PyObject *list, PyObject *item
}
3538 Appends the object
\var{item
} at the end of list
\var{list
}. Returns
3539 \code{0} if successful; returns
\code{-
1} and sets an exception if
3540 unsuccessful. Analogous to
\code{\var{list
}.append(
\var{item
})
}.
3543 \begin{cfuncdesc
}{PyObject*
}{PyList_GetSlice
}{PyObject *list,
3545 Returns a list of the objects in
\var{list
} containing the objects
3546 \emph{between
} \var{low
} and
\var{high
}. Returns NULL and sets an
3547 exception if unsuccessful.
3548 Analogous to
\code{\var{list
}[\var{low
}:
\var{high
}]}.
3551 \begin{cfuncdesc
}{int
}{PyList_SetSlice
}{PyObject *list,
3554 Sets the slice of
\var{list
} between
\var{low
} and
\var{high
} to the
3555 contents of
\var{itemlist
}. Analogous to
3556 \code{\var{list
}[\var{low
}:
\var{high
}] =
\var{itemlist
}}. Returns
3557 \code{0} on success,
\code{-
1} on failure.
3560 \begin{cfuncdesc
}{int
}{PyList_Sort
}{PyObject *list
}
3561 Sorts the items of
\var{list
} in place. Returns
\code{0} on success,
3562 \code{-
1} on failure. This is equivalent to
3563 \samp{\var{list
}.sort()
}.
3566 \begin{cfuncdesc
}{int
}{PyList_Reverse
}{PyObject *list
}
3567 Reverses the items of
\var{list
} in place. Returns
\code{0} on
3568 success,
\code{-
1} on failure. This is the equivalent of
3569 \samp{\var{list
}.reverse()
}.
3572 \begin{cfuncdesc
}{PyObject*
}{PyList_AsTuple
}{PyObject *list
}
3573 Returns a new tuple object containing the contents of
\var{list
};
3574 equivalent to
\samp{tuple(
\var{list
})
}.
\bifuncindex{tuple
}
3578 \section{Mapping Objects
\label{mapObjects
}}
3583 \subsection{Dictionary Objects
\label{dictObjects
}}
3585 \obindex{dictionary
}
3586 \begin{ctypedesc
}{PyDictObject
}
3587 This subtype of
\ctype{PyObject
} represents a Python dictionary object.
3590 \begin{cvardesc
}{PyTypeObject
}{PyDict_Type
}
3591 This instance of
\ctype{PyTypeObject
} represents the Python dictionary
3592 type. This is exposed to Python programs as
\code{types.DictType
} and
3593 \code{types.DictionaryType
}.
3594 \withsubitem{(in module types)
}{\ttindex{DictType
}\ttindex{DictionaryType
}}
3597 \begin{cfuncdesc
}{int
}{PyDict_Check
}{PyObject *p
}
3598 Returns true if its argument is a
\ctype{PyDictObject
}.
3601 \begin{cfuncdesc
}{PyObject*
}{PyDict_New
}{}
3602 Returns a new empty dictionary, or
\NULL{} on failure.
3605 \begin{cfuncdesc
}{void
}{PyDict_Clear
}{PyObject *p
}
3606 Empties an existing dictionary of all key-value pairs.
3609 \begin{cfuncdesc
}{PyObject*
}{PyDict_Copy
}{PyObject *p
}
3610 Returns a new dictionary that contains the same key-value pairs as p.
3611 Empties an existing dictionary of all key-value pairs.
3614 \begin{cfuncdesc
}{int
}{PyDict_SetItem
}{PyObject *p, PyObject *key,
3616 Inserts
\var{value
} into the dictionary
\var{p
} with a key of
\var{key
}.
3617 \var{key
} must be hashable; if it isn't,
\exception{TypeError
} will be
3619 Returns
\code{0} on success or
\code{-
1} on failure.
3622 \begin{cfuncdesc
}{int
}{PyDict_SetItemString
}{PyObject *p,
3625 Inserts
\var{value
} into the dictionary
\var{p
} using
\var{key
}
3626 as a key.
\var{key
} should be a
\ctype{char*
}. The key object is
3627 created using
\code{PyString_FromString(
\var{key
})
}.
3628 Returns
\code{0} on success or
\code{-
1} on failure.
3629 \ttindex{PyString_FromString()
}
3632 \begin{cfuncdesc
}{int
}{PyDict_DelItem
}{PyObject *p, PyObject *key
}
3633 Removes the entry in dictionary
\var{p
} with key
\var{key
}.
3634 \var{key
} must be hashable; if it isn't,
\exception{TypeError
} is
3638 \begin{cfuncdesc
}{int
}{PyDict_DelItemString
}{PyObject *p, char *key
}
3639 Removes the entry in dictionary
\var{p
} which has a key
3640 specified by the string
\var{key
}.
3641 Returns
\code{0} on success or
\code{-
1} on failure.
3644 \begin{cfuncdesc
}{PyObject*
}{PyDict_GetItem
}{PyObject *p, PyObject *key
}
3645 Returns the object from dictionary
\var{p
} which has a key
3646 \var{key
}. Returns
\NULL{} if the key
\var{key
} is not present, but
3647 \emph{without
} setting an exception.
3650 \begin{cfuncdesc
}{PyObject*
}{PyDict_GetItemString
}{PyObject *p, char *key
}
3651 This is the same as
\cfunction{PyDict_GetItem()
}, but
\var{key
} is
3652 specified as a
\ctype{char*
}, rather than a
\ctype{PyObject*
}.
3655 \begin{cfuncdesc
}{PyObject*
}{PyDict_Items
}{PyObject *p
}
3656 Returns a
\ctype{PyListObject
} containing all the items
3657 from the dictionary, as in the dictinoary method
\method{items()
} (see
3658 the
\citetitle[../lib/lib.html
]{Python Library Reference
}).
3661 \begin{cfuncdesc
}{PyObject*
}{PyDict_Keys
}{PyObject *p
}
3662 Returns a
\ctype{PyListObject
} containing all the keys
3663 from the dictionary, as in the dictionary method
\method{keys()
} (see the
3664 \citetitle[../lib/lib.html
]{Python Library Reference
}).
3667 \begin{cfuncdesc
}{PyObject*
}{PyDict_Values
}{PyObject *p
}
3668 Returns a
\ctype{PyListObject
} containing all the values
3669 from the dictionary
\var{p
}, as in the dictionary method
3670 \method{values()
} (see the
\citetitle[../lib/lib.html
]{Python Library
3674 \begin{cfuncdesc
}{int
}{PyDict_Size
}{PyObject *p
}
3675 Returns the number of items in the dictionary. This is equivalent to
3676 \samp{len(
\var{p
})
} on a dictionary.
\bifuncindex{len
}
3679 \begin{cfuncdesc
}{int
}{PyDict_Next
}{PyObject *p, int *ppos,
3680 PyObject **pkey, PyObject **pvalue
}
3681 Iterate over all key-value pairs in the dictionary
\var{p
}. The
3682 \ctype{int
} referred to by
\var{ppos
} must be initialized to
\code{0}
3683 prior to the first call to this function to start the iteration; the
3684 function returns true for each pair in the dictionary, and false once
3685 all pairs have been reported. The parameters
\var{pkey
} and
3686 \var{pvalue
} should either point to
\ctype{PyObject*
} variables that
3687 will be filled in with each key and value, respectively, or may be
3693 PyObject *key, *value;
3696 while (PyDict_Next(self->dict, &pos, &key, &value))
{
3697 /* do something interesting with the values... */
3702 The dictionary
\var{p
} should not be mutated during iteration. It is
3703 safe (since Python
2.1) to modify the values of the keys as you
3704 iterate over the dictionary, for example:
3707 PyObject *key, *value;
3710 while (PyDict_Next(self->dict, &pos, &key, &value))
{
3711 int i = PyInt_AS_LONG(value) +
1;
3712 PyObject *o = PyInt_FromLong(i);
3715 if (PyDict_SetItem(self->dict, key, o) <
0)
{
3725 \section{Other Objects
\label{otherObjects
}}
3727 \subsection{File Objects
\label{fileObjects
}}
3730 Python's built-in file objects are implemented entirely on the
3731 \ctype{FILE*
} support from the C standard library. This is an
3732 implementation detail and may change in future releases of Python.
3734 \begin{ctypedesc
}{PyFileObject
}
3735 This subtype of
\ctype{PyObject
} represents a Python file object.
3738 \begin{cvardesc
}{PyTypeObject
}{PyFile_Type
}
3739 This instance of
\ctype{PyTypeObject
} represents the Python file
3740 type. This is exposed to Python programs as
\code{types.FileType
}.
3741 \withsubitem{(in module types)
}{\ttindex{FileType
}}
3744 \begin{cfuncdesc
}{int
}{PyFile_Check
}{PyObject *p
}
3745 Returns true if its argument is a
\ctype{PyFileObject
}.
3748 \begin{cfuncdesc
}{PyObject*
}{PyFile_FromString
}{char *filename, char *mode
}
3749 On success, returns a new file object that is opened on the
3750 file given by
\var{filename
}, with a file mode given by
\var{mode
},
3751 where
\var{mode
} has the same semantics as the standard C routine
3752 \cfunction{fopen()
}\ttindex{fopen()
}. On failure, returns
\NULL.
3755 \begin{cfuncdesc
}{PyObject*
}{PyFile_FromFile
}{FILE *fp,
3756 char *name, char *mode,
3757 int
(*close)(FILE*)}
3758 Creates a new
\ctype{PyFileObject
} from the already-open standard C
3759 file pointer,
\var{fp
}. The function
\var{close
} will be called when
3760 the file should be closed. Returns
\NULL{} on failure.
3763 \begin{cfuncdesc
}{FILE*
}{PyFile_AsFile
}{PyFileObject *p
}
3764 Returns the file object associated with
\var{p
} as a
\ctype{FILE*
}.
3767 \begin{cfuncdesc
}{PyObject*
}{PyFile_GetLine
}{PyObject *p, int n
}
3768 Equivalent to
\code{\var{p
}.readline(
\optional{\var{n
}})
}, this
3769 function reads one line from the object
\var{p
}.
\var{p
} may be a
3770 file object or any object with a
\method{readline()
} method. If
3771 \var{n
} is
\code{0}, exactly one line is read, regardless of the
3772 length of the line. If
\var{n
} is greater than
\code{0}, no more than
3773 \var{n
} bytes will be read from the file; a partial line can be
3774 returned. In both cases, an empty string is returned if the end of
3775 the file is reached immediately. If
\var{n
} is less than
\code{0},
3776 however, one line is read regardless of length, but
3777 \exception{EOFError
} is raised if the end of the file is reached
3779 \withsubitem{(built-in exception)
}{\ttindex{EOFError
}}
3782 \begin{cfuncdesc
}{PyObject*
}{PyFile_Name
}{PyObject *p
}
3783 Returns the name of the file specified by
\var{p
} as a string object.
3786 \begin{cfuncdesc
}{void
}{PyFile_SetBufSize
}{PyFileObject *p, int n
}
3787 Available on systems with
\cfunction{setvbuf()
}\ttindex{setvbuf()
}
3788 only. This should only be called immediately after file object
3792 \begin{cfuncdesc
}{int
}{PyFile_SoftSpace
}{PyObject *p, int newflag
}
3793 This function exists for internal use by the interpreter.
3794 Sets the
\member{softspace
} attribute of
\var{p
} to
\var{newflag
} and
3795 \withsubitem{(file attribute)
}{\ttindex{softspace
}}returns the
3796 previous value.
\var{p
} does not have to be a file object
3797 for this function to work properly; any object is supported (thought
3798 its only interesting if the
\member{softspace
} attribute can be set).
3799 This function clears any errors, and will return
\code{0} as the
3800 previous value if the attribute either does not exist or if there were
3801 errors in retrieving it. There is no way to detect errors from this
3802 function, but doing so should not be needed.
3805 \begin{cfuncdesc
}{int
}{PyFile_WriteObject
}{PyObject *obj, PyFileObject *p,
3807 Writes object
\var{obj
} to file object
\var{p
}. The only supported
3808 flag for
\var{flags
} is
\constant{Py_PRINT_RAW
}\ttindex{Py_PRINT_RAW
};
3809 if given, the
\function{str()
} of the object is written instead of the
3810 \function{repr()
}. Returns
\code{0} on success or
\code{-
1} on
3811 failure; the appropriate exception will be set.
3814 \begin{cfuncdesc
}{int
}{PyFile_WriteString
}{char *s, PyFileObject *p,
3816 Writes string
\var{s
} to file object
\var{p
}. Returns
\code{0} on
3817 success or
\code{-
1} on failure; the appropriate exception will be
3822 \subsection{Instance Objects
\label{instanceObjects
}}
3825 There are very few functions specific to instance objects.
3827 \begin{cvardesc
}{PyTypeObject
}{PyInstance_Type
}
3828 Type object for class instances.
3831 \begin{cfuncdesc
}{int
}{PyInstance_Check
}{PyObject *obj
}
3832 Returns true if
\var{obj
} is an instance.
3835 \begin{cfuncdesc
}{PyObject*
}{PyInstance_New
}{PyObject *class,
3838 Create a new instance of a specific class. The parameters
\var{arg
}
3839 and
\var{kw
} are used as the positional and keyword parameters to
3840 the object's constructor.
3843 \begin{cfuncdesc
}{PyObject*
}{PyInstance_NewRaw
}{PyObject *class,
3845 Create a new instance of a specific class without calling it's
3846 constructor.
\var{class
} is the class of new object. The
3847 \var{dict
} parameter will be used as the object's
\member{__dict__
};
3848 if
\NULL, a new dictionary will be created for the instance.
3852 \subsection{Module Objects
\label{moduleObjects
}}
3855 There are only a few functions special to module objects.
3857 \begin{cvardesc
}{PyTypeObject
}{PyModule_Type
}
3858 This instance of
\ctype{PyTypeObject
} represents the Python module
3859 type. This is exposed to Python programs as
\code{types.ModuleType
}.
3860 \withsubitem{(in module types)
}{\ttindex{ModuleType
}}
3863 \begin{cfuncdesc
}{int
}{PyModule_Check
}{PyObject *p
}
3864 Returns true if its argument is a module object.
3867 \begin{cfuncdesc
}{PyObject*
}{PyModule_New
}{char *name
}
3868 Return a new module object with the
\member{__name__
} attribute set to
3869 \var{name
}. Only the module's
\member{__doc__
} and
3870 \member{__name__
} attributes are filled in; the caller is responsible
3871 for providing a
\member{__file__
} attribute.
3872 \withsubitem{(module attribute)
}{
3873 \ttindex{__name__
}\ttindex{__doc__
}\ttindex{__file__
}}
3876 \begin{cfuncdesc
}{PyObject*
}{PyModule_GetDict
}{PyObject *module
}
3877 Return the dictionary object that implements
\var{module
}'s namespace;
3878 this object is the same as the
\member{__dict__
} attribute of the
3879 module object. This function never fails.
3880 \withsubitem{(module attribute)
}{\ttindex{__dict__
}}
3883 \begin{cfuncdesc
}{char*
}{PyModule_GetName
}{PyObject *module
}
3884 Return
\var{module
}'s
\member{__name__
} value. If the module does not
3885 provide one, or if it is not a string,
\exception{SystemError
} is
3886 raised and
\NULL{} is returned.
3887 \withsubitem{(module attribute)
}{\ttindex{__name__
}}
3888 \withsubitem{(built-in exception)
}{\ttindex{SystemError
}}
3891 \begin{cfuncdesc
}{char*
}{PyModule_GetFilename
}{PyObject *module
}
3892 Return the name of the file from which
\var{module
} was loaded using
3893 \var{module
}'s
\member{__file__
} attribute. If this is not defined,
3894 or if it is not a string, raise
\exception{SystemError
} and return
3896 \withsubitem{(module attribute)
}{\ttindex{__file__
}}
3897 \withsubitem{(built-in exception)
}{\ttindex{SystemError
}}
3900 \begin{cfuncdesc
}{int
}{PyModule_AddObject
}{PyObject *module,
3901 char *name, PyObject *value
}
3902 Add an object to
\var{module
} as
\var{name
}. This is a convenience
3903 function which can be used from the module's initialization function.
3904 This steals a reference to
\var{value
}. Returns
\code{-
1} on error,
3905 \code{0} on success.
3909 \begin{cfuncdesc
}{int
}{PyModule_AddIntConstant
}{PyObject *module,
3910 char *name, int value
}
3911 Add an integer constant to
\var{module
} as
\var{name
}. This convenience
3912 function can be used from the module's initialization function.
3913 Returns
\code{-
1} on error,
\code{0} on success.
3917 \begin{cfuncdesc
}{int
}{PyModule_AddStringConstant
}{PyObject *module,
3918 char *name, char *value
}
3919 Add a string constant to
\var{module
} as
\var{name
}. This convenience
3920 function can be used from the module's initialization function. The
3921 string
\var{value
} must be null-terminated. Returns
\code{-
1} on
3922 error,
\code{0} on success.
3927 \subsection{CObjects
\label{cObjects
}}
3930 Refer to
\emph{Extending and Embedding the Python Interpreter
},
3931 section
1.12 (``Providing a C API for an Extension Module''), for more
3932 information on using these objects.
3935 \begin{ctypedesc
}{PyCObject
}
3936 This subtype of
\ctype{PyObject
} represents an opaque value, useful for
3937 C extension modules who need to pass an opaque value (as a
3938 \ctype{void*
} pointer) through Python code to other C code. It is
3939 often used to make a C function pointer defined in one module
3940 available to other modules, so the regular import mechanism can be
3941 used to access C APIs defined in dynamically loaded modules.
3944 \begin{cfuncdesc
}{int
}{PyCObject_Check
}{PyObject *p
}
3945 Returns true if its argument is a
\ctype{PyCObject
}.
3948 \begin{cfuncdesc
}{PyObject*
}{PyCObject_FromVoidPtr
}{void* cobj,
3949 void
(*destr)(void *)}
3950 Creates a
\ctype{PyCObject
} from the
\code{void *
}\var{cobj
}. The
3951 \var{destr
} function will be called when the object is reclaimed, unless
3955 \begin{cfuncdesc
}{PyObject*
}{PyCObject_FromVoidPtrAndDesc
}{void* cobj,
3956 void* desc, void
(*destr)(void *, void *) }
3957 Creates a
\ctype{PyCObject
} from the
\ctype{void *
}\var{cobj
}. The
3958 \var{destr
} function will be called when the object is reclaimed. The
3959 \var{desc
} argument can be used to pass extra callback data for the
3960 destructor function.
3963 \begin{cfuncdesc
}{void*
}{PyCObject_AsVoidPtr
}{PyObject* self
}
3964 Returns the object
\ctype{void *
} that the
3965 \ctype{PyCObject
} \var{self
} was created with.
3968 \begin{cfuncdesc
}{void*
}{PyCObject_GetDesc
}{PyObject* self
}
3969 Returns the description
\ctype{void *
} that the
3970 \ctype{PyCObject
} \var{self
} was created with.
3974 \chapter{Initialization, Finalization, and Threads
3975 \label{initialization
}}
3977 \begin{cfuncdesc
}{void
}{Py_Initialize
}{}
3978 Initialize the Python interpreter. In an application embedding
3979 Python, this should be called before using any other Python/C API
3980 functions; with the exception of
3981 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
},
3982 \cfunction{PyEval_InitThreads()
}\ttindex{PyEval_InitThreads()
},
3983 \cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
},
3984 and
\cfunction{PyEval_AcquireLock()
}\ttindex{PyEval_AcquireLock()
}.
3985 This initializes the table of loaded modules (
\code{sys.modules
}), and
3986 \withsubitem{(in module sys)
}{\ttindex{modules
}\ttindex{path
}}creates the
3987 fundamental modules
\module{__builtin__
}\refbimodindex{__builtin__
},
3988 \module{__main__
}\refbimodindex{__main__
} and
3989 \module{sys
}\refbimodindex{sys
}. It also initializes the module
3990 search
\indexiii{module
}{search
}{path
} path (
\code{sys.path
}).
3991 It does not set
\code{sys.argv
}; use
3992 \cfunction{PySys_SetArgv()
}\ttindex{PySys_SetArgv()
} for that. This
3993 is a no-op when called for a second time (without calling
3994 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} first). There is no
3995 return value; it is a fatal error if the initialization fails.
3998 \begin{cfuncdesc
}{int
}{Py_IsInitialized
}{}
3999 Return true (nonzero) when the Python interpreter has been
4000 initialized, false (zero) if not. After
\cfunction{Py_Finalize()
} is
4001 called, this returns false until
\cfunction{Py_Initialize()
} is called
4005 \begin{cfuncdesc
}{void
}{Py_Finalize
}{}
4006 Undo all initializations made by
\cfunction{Py_Initialize()
} and
4007 subsequent use of Python/C API functions, and destroy all
4008 sub-interpreters (see
\cfunction{Py_NewInterpreter()
} below) that were
4009 created and not yet destroyed since the last call to
4010 \cfunction{Py_Initialize()
}. Ideally, this frees all memory allocated
4011 by the Python interpreter. This is a no-op when called for a second
4012 time (without calling
\cfunction{Py_Initialize()
} again first). There
4013 is no return value; errors during finalization are ignored.
4015 This function is provided for a number of reasons. An embedding
4016 application might want to restart Python without having to restart the
4017 application itself. An application that has loaded the Python
4018 interpreter from a dynamically loadable library (or DLL) might want to
4019 free all memory allocated by Python before unloading the DLL. During a
4020 hunt for memory leaks in an application a developer might want to free
4021 all memory allocated by Python before exiting from the application.
4023 \strong{Bugs and caveats:
} The destruction of modules and objects in
4024 modules is done in random order; this may cause destructors
4025 (
\method{__del__()
} methods) to fail when they depend on other objects
4026 (even functions) or modules. Dynamically loaded extension modules
4027 loaded by Python are not unloaded. Small amounts of memory allocated
4028 by the Python interpreter may not be freed (if you find a leak, please
4029 report it). Memory tied up in circular references between objects is
4030 not freed. Some memory allocated by extension modules may not be
4031 freed. Some extension may not work properly if their initialization
4032 routine is called more than once; this can happen if an applcation
4033 calls
\cfunction{Py_Initialize()
} and
\cfunction{Py_Finalize()
} more
4037 \begin{cfuncdesc
}{PyThreadState*
}{Py_NewInterpreter
}{}
4038 Create a new sub-interpreter. This is an (almost) totally separate
4039 environment for the execution of Python code. In particular, the new
4040 interpreter has separate, independent versions of all imported
4041 modules, including the fundamental modules
4042 \module{__builtin__
}\refbimodindex{__builtin__
},
4043 \module{__main__
}\refbimodindex{__main__
} and
4044 \module{sys
}\refbimodindex{sys
}. The table of loaded modules
4045 (
\code{sys.modules
}) and the module search path (
\code{sys.path
}) are
4046 also separate. The new environment has no
\code{sys.argv
} variable.
4047 It has new standard I/O stream file objects
\code{sys.stdin
},
4048 \code{sys.stdout
} and
\code{sys.stderr
} (however these refer to the
4049 same underlying
\ctype{FILE
} structures in the C library).
4050 \withsubitem{(in module sys)
}{
4051 \ttindex{stdout
}\ttindex{stderr
}\ttindex{stdin
}}
4053 The return value points to the first thread state created in the new
4054 sub-interpreter. This thread state is made the current thread state.
4055 Note that no actual thread is created; see the discussion of thread
4056 states below. If creation of the new interpreter is unsuccessful,
4057 \NULL{} is returned; no exception is set since the exception state
4058 is stored in the current thread state and there may not be a current
4059 thread state. (Like all other Python/C API functions, the global
4060 interpreter lock must be held before calling this function and is
4061 still held when it returns; however, unlike most other Python/C API
4062 functions, there needn't be a current thread state on entry.)
4064 Extension modules are shared between (sub-)interpreters as follows:
4065 the first time a particular extension is imported, it is initialized
4066 normally, and a (shallow) copy of its module's dictionary is
4067 squirreled away. When the same extension is imported by another
4068 (sub-)interpreter, a new module is initialized and filled with the
4069 contents of this copy; the extension's
\code{init
} function is not
4070 called. Note that this is different from what happens when an
4071 extension is imported after the interpreter has been completely
4072 re-initialized by calling
4073 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} and
4074 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
}; in that case,
4075 the extension's
\code{init
\var{module
}} function
\emph{is
} called
4078 \strong{Bugs and caveats:
} Because sub-interpreters (and the main
4079 interpreter) are part of the same process, the insulation between them
4080 isn't perfect --- for example, using low-level file operations like
4081 \withsubitem{(in module os)
}{\ttindex{close()
}}
4082 \function{os.close()
} they can (accidentally or maliciously) affect each
4083 other's open files. Because of the way extensions are shared between
4084 (sub-)interpreters, some extensions may not work properly; this is
4085 especially likely when the extension makes use of (static) global
4086 variables, or when the extension manipulates its module's dictionary
4087 after its initialization. It is possible to insert objects created in
4088 one sub-interpreter into a namespace of another sub-interpreter; this
4089 should be done with great care to avoid sharing user-defined
4090 functions, methods, instances or classes between sub-interpreters,
4091 since import operations executed by such objects may affect the
4092 wrong (sub-)interpreter's dictionary of loaded modules. (XXX This is
4093 a hard-to-fix bug that will be addressed in a future release.)
4096 \begin{cfuncdesc
}{void
}{Py_EndInterpreter
}{PyThreadState *tstate
}
4097 Destroy the (sub-)interpreter represented by the given thread state.
4098 The given thread state must be the current thread state. See the
4099 discussion of thread states below. When the call returns, the current
4100 thread state is
\NULL{}. All thread states associated with this
4101 interpreted are destroyed. (The global interpreter lock must be held
4102 before calling this function and is still held when it returns.)
4103 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} will destroy all
4104 sub-interpreters that haven't been explicitly destroyed at that point.
4107 \begin{cfuncdesc
}{void
}{Py_SetProgramName
}{char *name
}
4108 This function should be called before
4109 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
} is called
4110 for the first time, if it is called at all. It tells the interpreter
4111 the value of the
\code{argv
[0]} argument to the
4112 \cfunction{main()
}\ttindex{main()
} function of the program. This is
4113 used by
\cfunction{Py_GetPath()
}\ttindex{Py_GetPath()
} and some other
4114 functions below to find the Python run-time libraries relative to the
4115 interpreter executable. The default value is
\code{'python'
}. The
4116 argument should point to a zero-terminated character string in static
4117 storage whose contents will not change for the duration of the
4118 program's execution. No code in the Python interpreter will change
4119 the contents of this storage.
4122 \begin{cfuncdesc
}{char*
}{Py_GetProgramName
}{}
4123 Return the program name set with
4124 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
}, or the
4125 default. The returned string points into static storage; the caller
4126 should not modify its value.
4129 \begin{cfuncdesc
}{char*
}{Py_GetPrefix
}{}
4130 Return the
\emph{prefix
} for installed platform-independent files. This
4131 is derived through a number of complicated rules from the program name
4132 set with
\cfunction{Py_SetProgramName()
} and some environment variables;
4133 for example, if the program name is
\code{'/usr/local/bin/python'
},
4134 the prefix is
\code{'/usr/local'
}. The returned string points into
4135 static storage; the caller should not modify its value. This
4136 corresponds to the
\makevar{prefix
} variable in the top-level
4137 \file{Makefile
} and the
\longprogramopt{prefix
} argument to the
4138 \program{configure
} script at build time. The value is available to
4139 Python code as
\code{sys.prefix
}. It is only useful on
\UNIX{}. See
4140 also the next function.
4143 \begin{cfuncdesc
}{char*
}{Py_GetExecPrefix
}{}
4144 Return the
\emph{exec-prefix
} for installed platform-
\emph{de
}pendent
4145 files. This is derived through a number of complicated rules from the
4146 program name set with
\cfunction{Py_SetProgramName()
} and some environment
4147 variables; for example, if the program name is
4148 \code{'/usr/local/bin/python'
}, the exec-prefix is
4149 \code{'/usr/local'
}. The returned string points into static storage;
4150 the caller should not modify its value. This corresponds to the
4151 \makevar{exec_prefix
} variable in the top-level
\file{Makefile
} and the
4152 \longprogramopt{exec-prefix
} argument to the
4153 \program{configure
} script at build time. The value is available to
4154 Python code as
\code{sys.exec_prefix
}. It is only useful on
\UNIX{}.
4156 Background: The exec-prefix differs from the prefix when platform
4157 dependent files (such as executables and shared libraries) are
4158 installed in a different directory tree. In a typical installation,
4159 platform dependent files may be installed in the
4160 \file{/usr/local/plat
} subtree while platform independent may be
4161 installed in
\file{/usr/local
}.
4163 Generally speaking, a platform is a combination of hardware and
4164 software families, e.g. Sparc machines running the Solaris
2.x
4165 operating system are considered the same platform, but Intel machines
4166 running Solaris
2.x are another platform, and Intel machines running
4167 Linux are yet another platform. Different major revisions of the same
4168 operating system generally also form different platforms. Non-
\UNIX{}
4169 operating systems are a different story; the installation strategies
4170 on those systems are so different that the prefix and exec-prefix are
4171 meaningless, and set to the empty string. Note that compiled Python
4172 bytecode files are platform independent (but not independent from the
4173 Python version by which they were compiled!).
4175 System administrators will know how to configure the
\program{mount
} or
4176 \program{automount
} programs to share
\file{/usr/local
} between platforms
4177 while having
\file{/usr/local/plat
} be a different filesystem for each
4181 \begin{cfuncdesc
}{char*
}{Py_GetProgramFullPath
}{}
4182 Return the full program name of the Python executable; this is
4183 computed as a side-effect of deriving the default module search path
4184 from the program name (set by
4185 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
} above).
4186 The returned string points into static storage; the caller should not
4187 modify its value. The value is available to Python code as
4188 \code{sys.executable
}.
4189 \withsubitem{(in module sys)
}{\ttindex{executable
}}
4192 \begin{cfuncdesc
}{char*
}{Py_GetPath
}{}
4193 \indexiii{module
}{search
}{path
}
4194 Return the default module search path; this is computed from the
4195 program name (set by
\cfunction{Py_SetProgramName()
} above) and some
4196 environment variables. The returned string consists of a series of
4197 directory names separated by a platform dependent delimiter character.
4198 The delimiter character is
\character{:
} on
\UNIX{},
\character{;
} on
4199 DOS/Windows, and
\character{\e n
} (the
\ASCII{} newline character) on
4200 Macintosh. The returned string points into static storage; the caller
4201 should not modify its value. The value is available to Python code
4202 as the list
\code{sys.path
}\withsubitem{(in module sys)
}{\ttindex{path
}},
4203 which may be modified to change the future search path for loaded
4206 % XXX should give the exact rules
4209 \begin{cfuncdesc
}{const char*
}{Py_GetVersion
}{}
4210 Return the version of this Python interpreter. This is a string that
4211 looks something like
4214 "
1.5 (
#67, Dec
31 1997,
22:
34:
28)
[GCC
2.7.2.2]"
4217 The first word (up to the first space character) is the current Python
4218 version; the first three characters are the major and minor version
4219 separated by a period. The returned string points into static storage;
4220 the caller should not modify its value. The value is available to
4221 Python code as the list
\code{sys.version
}.
4222 \withsubitem{(in module sys)
}{\ttindex{version
}}
4225 \begin{cfuncdesc
}{const char*
}{Py_GetPlatform
}{}
4226 Return the platform identifier for the current platform. On
\UNIX{},
4227 this is formed from the ``official'' name of the operating system,
4228 converted to lower case, followed by the major revision number; e.g.,
4229 for Solaris
2.x, which is also known as SunOS
5.x, the value is
4230 \code{'sunos5'
}. On Macintosh, it is
\code{'mac'
}. On Windows, it
4231 is
\code{'win'
}. The returned string points into static storage;
4232 the caller should not modify its value. The value is available to
4233 Python code as
\code{sys.platform
}.
4234 \withsubitem{(in module sys)
}{\ttindex{platform
}}
4237 \begin{cfuncdesc
}{const char*
}{Py_GetCopyright
}{}
4238 Return the official copyright string for the current Python version,
4241 \code{'Copyright
1991-
1995 Stichting Mathematisch Centrum, Amsterdam'
}
4243 The returned string points into static storage; the caller should not
4244 modify its value. The value is available to Python code as the list
4245 \code{sys.copyright
}.
4246 \withsubitem{(in module sys)
}{\ttindex{copyright
}}
4249 \begin{cfuncdesc
}{const char*
}{Py_GetCompiler
}{}
4250 Return an indication of the compiler used to build the current Python
4251 version, in square brackets, for example:
4257 The returned string points into static storage; the caller should not
4258 modify its value. The value is available to Python code as part of
4259 the variable
\code{sys.version
}.
4260 \withsubitem{(in module sys)
}{\ttindex{version
}}
4263 \begin{cfuncdesc
}{const char*
}{Py_GetBuildInfo
}{}
4264 Return information about the sequence number and build date and time
4265 of the current Python interpreter instance, for example
4268 "
#67, Aug
1 1997,
22:
34:
28"
4271 The returned string points into static storage; the caller should not
4272 modify its value. The value is available to Python code as part of
4273 the variable
\code{sys.version
}.
4274 \withsubitem{(in module sys)
}{\ttindex{version
}}
4277 \begin{cfuncdesc
}{int
}{PySys_SetArgv
}{int argc, char **argv
}
4278 Set
\code{sys.argv
} based on
\var{argc
} and
\var{argv
}. These
4279 parameters are similar to those passed to the program's
4280 \cfunction{main()
}\ttindex{main()
} function with the difference that
4281 the first entry should refer to the script file to be executed rather
4282 than the executable hosting the Python interpreter. If there isn't a
4283 script that will be run, the first entry in
\var{argv
} can be an empty
4284 string. If this function fails to initialize
\code{sys.argv
}, a fatal
4285 condition is signalled using
4286 \cfunction{Py_FatalError()
}\ttindex{Py_FatalError()
}.
4287 \withsubitem{(in module sys)
}{\ttindex{argv
}}
4288 % XXX impl. doesn't seem consistent in allowing 0/NULL for the params;
4292 % XXX Other PySys thingies (doesn't really belong in this chapter)
4294 \section{Thread State and the Global Interpreter Lock
4297 \index{global interpreter lock
}
4298 \index{interpreter lock
}
4299 \index{lock, interpreter
}
4301 The Python interpreter is not fully thread safe. In order to support
4302 multi-threaded Python programs, there's a global lock that must be
4303 held by the current thread before it can safely access Python objects.
4304 Without the lock, even the simplest operations could cause problems in
4305 a multi-threaded program: for example, when two threads simultaneously
4306 increment the reference count of the same object, the reference count
4307 could end up being incremented only once instead of twice.
4309 Therefore, the rule exists that only the thread that has acquired the
4310 global interpreter lock may operate on Python objects or call Python/C
4311 API functions. In order to support multi-threaded Python programs,
4312 the interpreter regularly releases and reacquires the lock --- by
4313 default, every ten bytecode instructions (this can be changed with
4314 \withsubitem{(in module sys)
}{\ttindex{setcheckinterval()
}}
4315 \function{sys.setcheckinterval()
}). The lock is also released and
4316 reacquired around potentially blocking I/O operations like reading or
4317 writing a file, so that other threads can run while the thread that
4318 requests the I/O is waiting for the I/O operation to complete.
4320 The Python interpreter needs to keep some bookkeeping information
4321 separate per thread --- for this it uses a data structure called
4322 \ctype{PyThreadState
}\ttindex{PyThreadState
}. This is new in Python
4323 1.5; in earlier versions, such state was stored in global variables,
4324 and switching threads could cause problems. In particular, exception
4325 handling is now thread safe, when the application uses
4326 \withsubitem{(in module sys)
}{\ttindex{exc_info()
}}
4327 \function{sys.exc_info()
} to access the exception last raised in the
4330 There's one global variable left, however: the pointer to the current
4331 \ctype{PyThreadState
}\ttindex{PyThreadState
} structure. While most
4332 thread packages have a way to store ``per-thread global data,''
4333 Python's internal platform independent thread abstraction doesn't
4334 support this yet. Therefore, the current thread state must be
4335 manipulated explicitly.
4337 This is easy enough in most cases. Most code manipulating the global
4338 interpreter lock has the following simple structure:
4341 Save the thread state in a local variable.
4342 Release the interpreter lock.
4343 ...Do some blocking I/O operation...
4344 Reacquire the interpreter lock.
4345 Restore the thread state from the local variable.
4348 This is so common that a pair of macros exists to simplify it:
4351 Py_BEGIN_ALLOW_THREADS
4352 ...Do some blocking I/O operation...
4353 Py_END_ALLOW_THREADS
4356 The
\code{Py_BEGIN_ALLOW_THREADS
}\ttindex{Py_BEGIN_ALLOW_THREADS
} macro
4357 opens a new block and declares a hidden local variable; the
4358 \code{Py_END_ALLOW_THREADS
}\ttindex{Py_END_ALLOW_THREADS
} macro closes
4359 the block. Another advantage of using these two macros is that when
4360 Python is compiled without thread support, they are defined empty,
4361 thus saving the thread state and lock manipulations.
4363 When thread support is enabled, the block above expands to the
4367 PyThreadState *_save;
4369 _save = PyEval_SaveThread();
4370 ...Do some blocking I/O operation...
4371 PyEval_RestoreThread(_save);
4374 Using even lower level primitives, we can get roughly the same effect
4378 PyThreadState *_save;
4380 _save = PyThreadState_Swap(NULL);
4381 PyEval_ReleaseLock();
4382 ...Do some blocking I/O operation...
4383 PyEval_AcquireLock();
4384 PyThreadState_Swap(_save);
4387 There are some subtle differences; in particular,
4388 \cfunction{PyEval_RestoreThread()
}\ttindex{PyEval_RestoreThread()
} saves
4389 and restores the value of the global variable
4390 \cdata{errno
}\ttindex{errno
}, since the lock manipulation does not
4391 guarantee that
\cdata{errno
} is left alone. Also, when thread support
4393 \cfunction{PyEval_SaveThread()
}\ttindex{PyEval_SaveThread()
} and
4394 \cfunction{PyEval_RestoreThread()
} don't manipulate the lock; in this
4395 case,
\cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
} and
4396 \cfunction{PyEval_AcquireLock()
}\ttindex{PyEval_AcquireLock()
} are not
4397 available. This is done so that dynamically loaded extensions
4398 compiled with thread support enabled can be loaded by an interpreter
4399 that was compiled with disabled thread support.
4401 The global interpreter lock is used to protect the pointer to the
4402 current thread state. When releasing the lock and saving the thread
4403 state, the current thread state pointer must be retrieved before the
4404 lock is released (since another thread could immediately acquire the
4405 lock and store its own thread state in the global variable).
4406 Conversely, when acquiring the lock and restoring the thread state,
4407 the lock must be acquired before storing the thread state pointer.
4409 Why am I going on with so much detail about this? Because when
4410 threads are created from C, they don't have the global interpreter
4411 lock, nor is there a thread state data structure for them. Such
4412 threads must bootstrap themselves into existence, by first creating a
4413 thread state data structure, then acquiring the lock, and finally
4414 storing their thread state pointer, before they can start using the
4415 Python/C API. When they are done, they should reset the thread state
4416 pointer, release the lock, and finally free their thread state data
4419 When creating a thread data structure, you need to provide an
4420 interpreter state data structure. The interpreter state data
4421 structure hold global data that is shared by all threads in an
4422 interpreter, for example the module administration
4423 (
\code{sys.modules
}). Depending on your needs, you can either create
4424 a new interpreter state data structure, or share the interpreter state
4425 data structure used by the Python main thread (to access the latter,
4426 you must obtain the thread state and access its
\member{interp
} member;
4427 this must be done by a thread that is created by Python or by the main
4428 thread after Python is initialized).
4431 \begin{ctypedesc
}{PyInterpreterState
}
4432 This data structure represents the state shared by a number of
4433 cooperating threads. Threads belonging to the same interpreter
4434 share their module administration and a few other internal items.
4435 There are no public members in this structure.
4437 Threads belonging to different interpreters initially share nothing,
4438 except process state like available memory, open file descriptors and
4439 such. The global interpreter lock is also shared by all threads,
4440 regardless of to which interpreter they belong.
4443 \begin{ctypedesc
}{PyThreadState
}
4444 This data structure represents the state of a single thread. The only
4445 public data member is
\ctype{PyInterpreterState *
}\member{interp
},
4446 which points to this thread's interpreter state.
4449 \begin{cfuncdesc
}{void
}{PyEval_InitThreads
}{}
4450 Initialize and acquire the global interpreter lock. It should be
4451 called in the main thread before creating a second thread or engaging
4452 in any other thread operations such as
4453 \cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
} or
4454 \code{PyEval_ReleaseThread(
\var{tstate
})
}\ttindex{PyEval_ReleaseThread()
}.
4455 It is not needed before calling
4456 \cfunction{PyEval_SaveThread()
}\ttindex{PyEval_SaveThread()
} or
4457 \cfunction{PyEval_RestoreThread()
}\ttindex{PyEval_RestoreThread()
}.
4459 This is a no-op when called for a second time. It is safe to call
4460 this function before calling
4461 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
}.
4463 When only the main thread exists, no lock operations are needed. This
4464 is a common situation (most Python programs do not use threads), and
4465 the lock operations slow the interpreter down a bit. Therefore, the
4466 lock is not created initially. This situation is equivalent to having
4467 acquired the lock: when there is only a single thread, all object
4468 accesses are safe. Therefore, when this function initializes the
4469 lock, it also acquires it. Before the Python
4470 \module{thread
}\refbimodindex{thread
} module creates a new thread,
4471 knowing that either it has the lock or the lock hasn't been created
4472 yet, it calls
\cfunction{PyEval_InitThreads()
}. When this call
4473 returns, it is guaranteed that the lock has been created and that it
4476 It is
\strong{not
} safe to call this function when it is unknown which
4477 thread (if any) currently has the global interpreter lock.
4479 This function is not available when thread support is disabled at
4483 \begin{cfuncdesc
}{void
}{PyEval_AcquireLock
}{}
4484 Acquire the global interpreter lock. The lock must have been created
4485 earlier. If this thread already has the lock, a deadlock ensues.
4486 This function is not available when thread support is disabled at
4490 \begin{cfuncdesc
}{void
}{PyEval_ReleaseLock
}{}
4491 Release the global interpreter lock. The lock must have been created
4492 earlier. This function is not available when thread support is
4493 disabled at compile time.
4496 \begin{cfuncdesc
}{void
}{PyEval_AcquireThread
}{PyThreadState *tstate
}
4497 Acquire the global interpreter lock and then set the current thread
4498 state to
\var{tstate
}, which should not be
\NULL{}. The lock must
4499 have been created earlier. If this thread already has the lock,
4500 deadlock ensues. This function is not available when thread support
4501 is disabled at compile time.
4504 \begin{cfuncdesc
}{void
}{PyEval_ReleaseThread
}{PyThreadState *tstate
}
4505 Reset the current thread state to
\NULL{} and release the global
4506 interpreter lock. The lock must have been created earlier and must be
4507 held by the current thread. The
\var{tstate
} argument, which must not
4508 be
\NULL{}, is only used to check that it represents the current
4509 thread state --- if it isn't, a fatal error is reported. This
4510 function is not available when thread support is disabled at compile
4514 \begin{cfuncdesc
}{PyThreadState*
}{PyEval_SaveThread
}{}
4515 Release the interpreter lock (if it has been created and thread
4516 support is enabled) and reset the thread state to
\NULL{},
4517 returning the previous thread state (which is not
\NULL{}). If
4518 the lock has been created, the current thread must have acquired it.
4519 (This function is available even when thread support is disabled at
4523 \begin{cfuncdesc
}{void
}{PyEval_RestoreThread
}{PyThreadState *tstate
}
4524 Acquire the interpreter lock (if it has been created and thread
4525 support is enabled) and set the thread state to
\var{tstate
}, which
4526 must not be
\NULL{}. If the lock has been created, the current
4527 thread must not have acquired it, otherwise deadlock ensues. (This
4528 function is available even when thread support is disabled at compile
4532 The following macros are normally used without a trailing semicolon;
4533 look for example usage in the Python source distribution.
4535 \begin{csimplemacrodesc
}{Py_BEGIN_ALLOW_THREADS
}
4536 This macro expands to
4537 \samp{\
{ PyThreadState *_save; _save = PyEval_SaveThread();
}.
4538 Note that it contains an opening brace; it must be matched with a
4539 following
\code{Py_END_ALLOW_THREADS
} macro. See above for further
4540 discussion of this macro. It is a no-op when thread support is
4541 disabled at compile time.
4542 \end{csimplemacrodesc
}
4544 \begin{csimplemacrodesc
}{Py_END_ALLOW_THREADS
}
4545 This macro expands to
4546 \samp{PyEval_RestoreThread(_save); \
}}.
4547 Note that it contains a closing brace; it must be matched with an
4548 earlier
\code{Py_BEGIN_ALLOW_THREADS
} macro. See above for further
4549 discussion of this macro. It is a no-op when thread support is
4550 disabled at compile time.
4551 \end{csimplemacrodesc
}
4553 \begin{csimplemacrodesc
}{Py_BLOCK_THREADS
}
4554 This macro expands to
\samp{PyEval_RestoreThread(_save);
}: it
4555 is equivalent to
\code{Py_END_ALLOW_THREADS
} without the closing
4556 brace. It is a no-op when thread support is disabled at compile
4558 \end{csimplemacrodesc
}
4560 \begin{csimplemacrodesc
}{Py_UNBLOCK_THREADS
}
4561 This macro expands to
\samp{_save = PyEval_SaveThread();
}: it is
4562 equivalent to
\code{Py_BEGIN_ALLOW_THREADS
} without the opening brace
4563 and variable declaration. It is a no-op when thread support is
4564 disabled at compile time.
4565 \end{csimplemacrodesc
}
4567 All of the following functions are only available when thread support
4568 is enabled at compile time, and must be called only when the
4569 interpreter lock has been created.
4571 \begin{cfuncdesc
}{PyInterpreterState*
}{PyInterpreterState_New
}{}
4572 Create a new interpreter state object. The interpreter lock need not
4573 be held, but may be held if it is necessary to serialize calls to this
4577 \begin{cfuncdesc
}{void
}{PyInterpreterState_Clear
}{PyInterpreterState *interp
}
4578 Reset all information in an interpreter state object. The interpreter
4582 \begin{cfuncdesc
}{void
}{PyInterpreterState_Delete
}{PyInterpreterState *interp
}
4583 Destroy an interpreter state object. The interpreter lock need not be
4584 held. The interpreter state must have been reset with a previous
4585 call to
\cfunction{PyInterpreterState_Clear()
}.
4588 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_New
}{PyInterpreterState *interp
}
4589 Create a new thread state object belonging to the given interpreter
4590 object. The interpreter lock need not be held, but may be held if it
4591 is necessary to serialize calls to this function.
4594 \begin{cfuncdesc
}{void
}{PyThreadState_Clear
}{PyThreadState *tstate
}
4595 Reset all information in a thread state object. The interpreter lock
4599 \begin{cfuncdesc
}{void
}{PyThreadState_Delete
}{PyThreadState *tstate
}
4600 Destroy a thread state object. The interpreter lock need not be
4601 held. The thread state must have been reset with a previous
4602 call to
\cfunction{PyThreadState_Clear()
}.
4605 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_Get
}{}
4606 Return the current thread state. The interpreter lock must be held.
4607 When the current thread state is
\NULL{}, this issues a fatal
4608 error (so that the caller needn't check for
\NULL{}).
4611 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_Swap
}{PyThreadState *tstate
}
4612 Swap the current thread state with the thread state given by the
4613 argument
\var{tstate
}, which may be
\NULL{}. The interpreter lock
4617 \begin{cfuncdesc
}{PyObject*
}{PyThreadState_GetDict
}{}
4618 Return a dictionary in which extensions can store thread-specific
4619 state information. Each extension should use a unique key to use to
4620 store state in the dictionary. If this function returns
\NULL, an
4621 exception has been raised and the caller should allow it to
4626 \chapter{Memory Management
\label{memory
}}
4627 \sectionauthor{Vladimir Marangozov
}{Vladimir.Marangozov@inrialpes.fr
}
4630 \section{Overview
\label{memoryOverview
}}
4632 Memory management in Python involves a private heap containing all
4633 Python objects and data structures. The management of this private
4634 heap is ensured internally by the
\emph{Python memory manager
}. The
4635 Python memory manager has different components which deal with various
4636 dynamic storage management aspects, like sharing, segmentation,
4637 preallocation or caching.
4639 At the lowest level, a raw memory allocator ensures that there is
4640 enough room in the private heap for storing all Python-related data
4641 by interacting with the memory manager of the operating system. On top
4642 of the raw memory allocator, several object-specific allocators
4643 operate on the same heap and implement distinct memory management
4644 policies adapted to the peculiarities of every object type. For
4645 example, integer objects are managed differently within the heap than
4646 strings, tuples or dictionaries because integers imply different
4647 storage requirements and speed/space tradeoffs. The Python memory
4648 manager thus delegates some of the work to the object-specific
4649 allocators, but ensures that the latter operate within the bounds of
4652 It is important to understand that the management of the Python heap
4653 is performed by the interpreter itself and that the user has no
4654 control on it, even if she regularly manipulates object pointers to
4655 memory blocks inside that heap. The allocation of heap space for
4656 Python objects and other internal buffers is performed on demand by
4657 the Python memory manager through the Python/C API functions listed in
4660 To avoid memory corruption, extension writers should never try to
4661 operate on Python objects with the functions exported by the C
4662 library:
\cfunction{malloc()
}\ttindex{malloc()
},
4663 \cfunction{calloc()
}\ttindex{calloc()
},
4664 \cfunction{realloc()
}\ttindex{realloc()
} and
4665 \cfunction{free()
}\ttindex{free()
}. This will result in
4666 mixed calls between the C allocator and the Python memory manager
4667 with fatal consequences, because they implement different algorithms
4668 and operate on different heaps. However, one may safely allocate and
4669 release memory blocks with the C library allocator for individual
4670 purposes, as shown in the following example:
4674 char *buf = (char *) malloc(BUFSIZ); /* for I/O */
4677 return PyErr_NoMemory();
4678 ...Do some I/O operation involving buf...
4679 res = PyString_FromString(buf);
4680 free(buf); /* malloc'ed */
4684 In this example, the memory request for the I/O buffer is handled by
4685 the C library allocator. The Python memory manager is involved only
4686 in the allocation of the string object returned as a result.
4688 In most situations, however, it is recommended to allocate memory from
4689 the Python heap specifically because the latter is under control of
4690 the Python memory manager. For example, this is required when the
4691 interpreter is extended with new object types written in C. Another
4692 reason for using the Python heap is the desire to
\emph{inform
} the
4693 Python memory manager about the memory needs of the extension module.
4694 Even when the requested memory is used exclusively for internal,
4695 highly-specific purposes, delegating all memory requests to the Python
4696 memory manager causes the interpreter to have a more accurate image of
4697 its memory footprint as a whole. Consequently, under certain
4698 circumstances, the Python memory manager may or may not trigger
4699 appropriate actions, like garbage collection, memory compaction or
4700 other preventive procedures. Note that by using the C library
4701 allocator as shown in the previous example, the allocated memory for
4702 the I/O buffer escapes completely the Python memory manager.
4705 \section{Memory Interface
\label{memoryInterface
}}
4707 The following function sets, modeled after the ANSI C standard, are
4708 available for allocating and releasing memory from the Python heap:
4711 \begin{cfuncdesc
}{void*
}{PyMem_Malloc
}{size_t n
}
4712 Allocates
\var{n
} bytes and returns a pointer of type
\ctype{void*
} to
4713 the allocated memory, or
\NULL{} if the request fails. Requesting zero
4714 bytes returns a non-
\NULL{} pointer.
4715 The memory will not have been initialized in any way.
4718 \begin{cfuncdesc
}{void*
}{PyMem_Realloc
}{void *p, size_t n
}
4719 Resizes the memory block pointed to by
\var{p
} to
\var{n
} bytes. The
4720 contents will be unchanged to the minimum of the old and the new
4721 sizes. If
\var{p
} is
\NULL{}, the call is equivalent to
4722 \cfunction{PyMem_Malloc(
\var{n
})
}; if
\var{n
} is equal to zero, the
4723 memory block is resized but is not freed, and the returned pointer is
4724 non-
\NULL{}. Unless
\var{p
} is
\NULL{}, it must have been returned by
4725 a previous call to
\cfunction{PyMem_Malloc()
} or
4726 \cfunction{PyMem_Realloc()
}.
4729 \begin{cfuncdesc
}{void
}{PyMem_Free
}{void *p
}
4730 Frees the memory block pointed to by
\var{p
}, which must have been
4731 returned by a previous call to
\cfunction{PyMem_Malloc()
} or
4732 \cfunction{PyMem_Realloc()
}. Otherwise, or if
4733 \cfunction{PyMem_Free(p)
} has been called before, undefined behaviour
4734 occurs. If
\var{p
} is
\NULL{}, no operation is performed.
4737 The following type-oriented macros are provided for convenience. Note
4738 that
\var{TYPE
} refers to any C type.
4740 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyMem_New
}{TYPE, size_t n
}
4741 Same as
\cfunction{PyMem_Malloc()
}, but allocates
\code{(
\var{n
} *
4742 sizeof(
\var{TYPE
}))
} bytes of memory. Returns a pointer cast to
4743 \ctype{\var{TYPE
}*
}.
4744 The memory will not have been initialized in any way.
4747 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyMem_Resize
}{void *p, TYPE, size_t n
}
4748 Same as
\cfunction{PyMem_Realloc()
}, but the memory block is resized
4749 to
\code{(
\var{n
} * sizeof(
\var{TYPE
}))
} bytes. Returns a pointer
4750 cast to
\ctype{\var{TYPE
}*
}.
4753 \begin{cfuncdesc
}{void
}{PyMem_Del
}{void *p
}
4754 Same as
\cfunction{PyMem_Free()
}.
4757 In addition, the following macro sets are provided for calling the
4758 Python memory allocator directly, without involving the C API functions
4759 listed above. However, note that their use does not preserve binary
4760 compatibility accross Python versions and is therefore deprecated in
4763 \cfunction{PyMem_MALLOC()
},
\cfunction{PyMem_REALLOC()
},
\cfunction{PyMem_FREE()
}.
4765 \cfunction{PyMem_NEW()
},
\cfunction{PyMem_RESIZE()
},
\cfunction{PyMem_DEL()
}.
4768 \section{Examples
\label{memoryExamples
}}
4770 Here is the example from section
\ref{memoryOverview
}, rewritten so
4771 that the I/O buffer is allocated from the Python heap by using the
4776 char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */
4779 return PyErr_NoMemory();
4780 /* ...Do some I/O operation involving buf... */
4781 res = PyString_FromString(buf);
4782 PyMem_Free(buf); /* allocated with PyMem_Malloc */
4786 The same code using the type-oriented function set:
4790 char *buf = PyMem_New(char, BUFSIZ); /* for I/O */
4793 return PyErr_NoMemory();
4794 /* ...Do some I/O operation involving buf... */
4795 res = PyString_FromString(buf);
4796 PyMem_Del(buf); /* allocated with PyMem_New */
4800 Note that in the two examples above, the buffer is always
4801 manipulated via functions belonging to the same set. Indeed, it
4802 is required to use the same memory API family for a given
4803 memory block, so that the risk of mixing different allocators is
4804 reduced to a minimum. The following code sequence contains two errors,
4805 one of which is labeled as
\emph{fatal
} because it mixes two different
4806 allocators operating on different heaps.
4809 char *buf1 = PyMem_New(char, BUFSIZ);
4810 char *buf2 = (char *) malloc(BUFSIZ);
4811 char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
4813 PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */
4814 free(buf2); /* Right -- allocated via malloc() */
4815 free(buf1); /* Fatal -- should be PyMem_Del() */
4818 In addition to the functions aimed at handling raw memory blocks from
4819 the Python heap, objects in Python are allocated and released with
4820 \cfunction{PyObject_New()
},
\cfunction{PyObject_NewVar()
} and
4821 \cfunction{PyObject_Del()
}, or with their corresponding macros
4822 \cfunction{PyObject_NEW()
},
\cfunction{PyObject_NEW_VAR()
} and
4823 \cfunction{PyObject_DEL()
}.
4825 These will be explained in the next chapter on defining and
4826 implementing new object types in C.
4829 \chapter{Defining New Object Types
\label{newTypes
}}
4831 \begin{cfuncdesc
}{PyObject*
}{_PyObject_New
}{PyTypeObject *type
}
4834 \begin{cfuncdesc
}{PyVarObject*
}{_PyObject_NewVar
}{PyTypeObject *type, int size
}
4837 \begin{cfuncdesc
}{void
}{_PyObject_Del
}{PyObject *op
}
4840 \begin{cfuncdesc
}{PyObject*
}{PyObject_Init
}{PyObject *op,
4842 Initialize a newly-allocated object
\var{op
} with its type and
4843 initial reference. Returns the initialized object. If
\var{type
}
4844 indicates that the object participates in the cyclic garbage
4845 detector, it it added to the detector's set of observed objects.
4846 Other fields of the object are not affected.
4849 \begin{cfuncdesc
}{PyVarObject*
}{PyObject_InitVar
}{PyVarObject *op,
4850 PyTypeObject *type, int size
}
4851 This does everything
\cfunction{PyObject_Init()
} does, and also
4852 initializes the length information for a variable-size object.
4855 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_New
}{TYPE, PyTypeObject *type
}
4856 Allocate a new Python object using the C structure type
\var{TYPE
}
4857 and the Python type object
\var{type
}. Fields not defined by the
4858 Python object header are not initialized; the object's reference
4859 count will be one. The size of the memory
4860 allocation is determined from the
\member{tp_basicsize
} field of the
4864 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NewVar
}{TYPE, PyTypeObject *type,
4866 Allocate a new Python object using the C structure type
\var{TYPE
}
4867 and the Python type object
\var{type
}. Fields not defined by the
4868 Python object header are not initialized. The allocated memory
4869 allows for the
\var{TYPE
} structure plus
\var{size
} fields of the
4870 size given by the
\member{tp_itemsize
} field of
\var{type
}. This is
4871 useful for implementing objects like tuples, which are able to
4872 determine their size at construction time. Embedding the array of
4873 fields into the same allocation decreases the number of allocations,
4874 improving the memory management efficiency.
4877 \begin{cfuncdesc
}{void
}{PyObject_Del
}{PyObject *op
}
4878 Releases memory allocated to an object using
4879 \cfunction{PyObject_New()
} or
\cfunction{PyObject_NewVar()
}. This
4880 is normally called from the
\member{tp_dealloc
} handler specified in
4881 the object's type. The fields of the object should not be accessed
4882 after this call as the memory is no longer a valid Python object.
4885 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NEW
}{TYPE, PyTypeObject *type
}
4886 Macro version of
\cfunction{PyObject_New()
}, to gain performance at
4887 the expense of safety. This does not check
\var{type
} for a
\NULL{}
4891 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NEW_VAR
}{TYPE, PyTypeObject *type,
4893 Macro version of
\cfunction{PyObject_NewVar()
}, to gain performance
4894 at the expense of safety. This does not check
\var{type
} for a
4898 \begin{cfuncdesc
}{void
}{PyObject_DEL
}{PyObject *op
}
4899 Macro version of
\cfunction{PyObject_Del()
}.
4902 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule
}{char *name,
4903 PyMethodDef *methods
}
4904 Create a new module object based on a name and table of functions,
4905 returning the new module object.
4908 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule3
}{char *name,
4909 PyMethodDef *methods,
4911 Create a new module object based on a name and table of functions,
4912 returning the new module object. If
\var{doc
} is non-
\NULL, it will
4913 be used to define the docstring for the module.
4916 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule4
}{char *name,
4917 PyMethodDef *methods,
4918 char *doc, PyObject *self,
4920 Create a new module object based on a name and table of functions,
4921 returning the new module object. If
\var{doc
} is non-
\NULL, it will
4922 be used to define the docstring for the module. If
\var{self
} is
4923 non-
\NULL, it will passed to the functions of the module as their
4924 (otherwise
\NULL) first parameter. (This was added as an
4925 experimental feature, and there are no known uses in the current
4926 version of Python.) For
\var{apiver
}, the only value which should
4927 be passed is defined by the constant
\constant{PYTHON_API_VERSION
}.
4929 \strong{Note:
} Most uses of this function should probably be using
4930 the
\cfunction{Py_InitModule3()
} instead; only use this if you are
4934 \begin{cfuncdesc
}{int
}{PyArg_ParseTuple
}{PyObject *args, char *format,
4936 Parse the parameters of a function that takes only positional
4937 parameters into local variables. See
4938 \citetitle[../ext/parseTuple.html
]{Extending and Embedding the
4939 Python Interpreter
} for more information.
4942 \begin{cfuncdesc
}{int
}{PyArg_ParseTupleAndKeywords
}{PyObject *args,
4943 PyObject *kw, char *format, char *keywords
[],
\moreargs}
4944 Parse the parameters of a function that takes both positional and
4945 keyword parameters into local variables. See
4946 \citetitle[../ext/parseTupleAndKeywords.html
]{Extending and
4947 Embedding the Python Interpreter
} for more information.
4950 \begin{cfuncdesc
}{int
}{PyArg_Parse
}{PyObject *args, char *format,
\moreargs}
4951 Function used to deconstruct the argument lists of ``old-style''
4952 functions --- these are functions which use the
4953 \constant{METH_OLDARGS
} parameter parsing method. This is not
4954 recommended for new code, and most code in the standard interpreter
4955 has been modified to no longer use this.
4962 \begin{cvardesc
}{PyObject
}{_Py_NoneStruct
}
4963 Object which is visible in Python as
\code{None
}. This should only
4964 be accessed using the
\code{Py_None
} macro, which evaluates to a
4965 pointer to this object.
4969 \section{Common Object Structures
\label{common-structs
}}
4971 PyObject, PyVarObject
4973 PyObject_HEAD, PyObject_HEAD_INIT, PyObject_VAR_HEAD
4976 unaryfunc, binaryfunc, ternaryfunc, inquiry, coercion, intargfunc,
4977 intintargfunc, intobjargproc, intintobjargproc, objobjargproc,
4978 destructor, printfunc, getattrfunc, getattrofunc, setattrfunc,
4979 setattrofunc, cmpfunc, reprfunc, hashfunc
4981 \begin{ctypedesc
}{PyCFunction
}
4982 Type of the functions used to implement most Python callables in C.
4985 \begin{ctypedesc
}{PyMethodDef
}
4986 Structure used to describe a method of an extension type. This
4987 structure has four fields:
4989 \begin{tableiii
}{l|l|l
}{member
}{Field
}{C Type
}{Meaning
}
4990 \lineiii{ml_name
}{char *
}{name of the method
}
4991 \lineiii{ml_meth
}{PyCFunction
}{pointer to the C implementation
}
4992 \lineiii{ml_flags
}{int
}{flag bits indicating how the call should be
4994 \lineiii{ml_doc
}{char *
}{points to the contents of the docstring
}
4998 \begin{cfuncdesc
}{PyObject*
}{Py_FindMethod
}{PyMethodDef
[] table,
4999 PyObject *ob, char *name
}
5000 Return a bound method object for an extension type implemented in C.
5001 This function also handles the special attribute
\member{__methods__
},
5002 returning a list of all the method names defined in
\var{table
}.
5006 \section{Mapping Object Structures
\label{mapping-structs
}}
5008 \begin{ctypedesc
}{PyMappingMethods
}
5009 Structure used to hold pointers to the functions used to implement the
5010 mapping protocol for an extension type.
5014 \section{Number Object Structures
\label{number-structs
}}
5016 \begin{ctypedesc
}{PyNumberMethods
}
5017 Structure used to hold pointers to the functions an extension type
5018 uses to implement the number protocol.
5022 \section{Sequence Object Structures
\label{sequence-structs
}}
5024 \begin{ctypedesc
}{PySequenceMethods
}
5025 Structure used to hold pointers to the functions which an object uses
5026 to implement the sequence protocol.
5030 \section{Buffer Object Structures
\label{buffer-structs
}}
5031 \sectionauthor{Greg J. Stein
}{greg@lyra.org
}
5033 The buffer interface exports a model where an object can expose its
5034 internal data as a set of chunks of data, where each chunk is
5035 specified as a pointer/length pair. These chunks are called
5036 \dfn{segments
} and are presumed to be non-contiguous in memory.
5038 If an object does not export the buffer interface, then its
5039 \member{tp_as_buffer
} member in the
\ctype{PyTypeObject
} structure
5040 should be
\NULL{}. Otherwise, the
\member{tp_as_buffer
} will point to
5041 a
\ctype{PyBufferProcs
} structure.
5043 \strong{Note:
} It is very important that your
5044 \ctype{PyTypeObject
} structure uses
\constant{Py_TPFLAGS_DEFAULT
} for
5045 the value of the
\member{tp_flags
} member rather than
\code{0}. This
5046 tells the Python runtime that your
\ctype{PyBufferProcs
} structure
5047 contains the
\member{bf_getcharbuffer
} slot. Older versions of Python
5048 did not have this member, so a new Python interpreter using an old
5049 extension needs to be able to test for its presence before using it.
5051 \begin{ctypedesc
}{PyBufferProcs
}
5052 Structure used to hold the function pointers which define an
5053 implementation of the buffer protocol.
5055 The first slot is
\member{bf_getreadbuffer
}, of type
5056 \ctype{getreadbufferproc
}. If this slot is
\NULL{}, then the object
5057 does not support reading from the internal data. This is
5058 non-sensical, so implementors should fill this in, but callers should
5059 test that the slot contains a non-
\NULL{} value.
5061 The next slot is
\member{bf_getwritebuffer
} having type
5062 \ctype{getwritebufferproc
}. This slot may be
\NULL{} if the object
5063 does not allow writing into its returned buffers.
5065 The third slot is
\member{bf_getsegcount
}, with type
5066 \ctype{getsegcountproc
}. This slot must not be
\NULL{} and is used to
5067 inform the caller how many segments the object contains. Simple
5068 objects such as
\ctype{PyString_Type
} and
5069 \ctype{PyBuffer_Type
} objects contain a single segment.
5071 The last slot is
\member{bf_getcharbuffer
}, of type
5072 \ctype{getcharbufferproc
}. This slot will only be present if the
5073 \constant{Py_TPFLAGS_HAVE_GETCHARBUFFER
} flag is present in the
5074 \member{tp_flags
} field of the object's
\ctype{PyTypeObject
}. Before using
5075 this slot, the caller should test whether it is present by using the
5076 \cfunction{PyType_HasFeature()
}\ttindex{PyType_HasFeature()
} function.
5077 If present, it may be
\NULL, indicating that the object's contents
5078 cannot be used as
\emph{8-bit characters
}.
5079 The slot function may also raise an error if the object's contents
5080 cannot be interpreted as
8-bit characters. For example, if the object
5081 is an array which is configured to hold floating point values, an
5082 exception may be raised if a caller attempts to use
5083 \member{bf_getcharbuffer
} to fetch a sequence of
8-bit characters.
5084 This notion of exporting the internal buffers as ``text'' is used to
5085 distinguish between objects that are binary in nature, and those which
5086 have character-based content.
5088 \strong{Note:
} The current policy seems to state that these characters
5089 may be multi-byte characters. This implies that a buffer size of
5090 \var{N
} does not mean there are
\var{N
} characters present.
5093 \begin{datadesc
}{Py_TPFLAGS_HAVE_GETCHARBUFFER
}
5094 Flag bit set in the type structure to indicate that the
5095 \member{bf_getcharbuffer
} slot is known. This being set does not
5096 indicate that the object supports the buffer interface or that the
5097 \member{bf_getcharbuffer
} slot is non-
\NULL.
5100 \begin{ctypedesc
}[getreadbufferproc
]{int
(*getreadbufferproc)
5101 (PyObject *self, int segment, void **ptrptr)}
5102 Return a pointer to a readable segment of the buffer. This function
5103 is allowed to raise an exception, in which case it must return
5104 \code{-1}. The \var{segment} which is passed must be zero or
5105 positive, and strictly less than the number of segments returned by
5106 the \member{bf_getsegcount} slot function. On success, it returns the
5107 length of the buffer memory, and sets \code{*\var{ptrptr}} to a
5108 pointer to that memory.
5111 \begin{ctypedesc}[getwritebufferproc]{int (*getwritebufferproc)
5112 (PyObject *self, int segment, void **ptrptr)}
5113 Return a pointer to a writable memory buffer in \code{*\var{ptrptr}},
5114 and the length of that segment as the function return value.
5115 The memory buffer must correspond to buffer segment \var{segment}.
5116 Must return \code{-1} and set an exception on error.
5117 \exception{TypeError} should be raised if the object only supports
5118 read-only buffers, and \exception{SystemError} should be raised when
5119 \var{segment} specifies a segment that doesn't exist.
5120 % Why doesn't it raise ValueError for this one?
5121 % GJS: because you shouldn't be calling it with an invalid
5122 % segment. That indicates a blatant programming error in the C
5126 \begin{ctypedesc}[getsegcountproc]{int (*getsegcountproc)
5127 (PyObject *self, int *lenp)}
5128 Return the number of memory segments which comprise the buffer. If
5129 \var{lenp} is not \NULL, the implementation must report the sum of the
5130 sizes (in bytes) of all segments in \code{*\var{lenp}}.
5131 The function cannot fail.
5134 \begin{ctypedesc}[getcharbufferproc]{int (*getcharbufferproc)
5135 (PyObject *self, int segment, const char **ptrptr)}
5139 \section{Supporting Cyclic Garbarge Collection
5140 \label{supporting-cycle-detection}}
5142 Python's support for detecting and collecting garbage which involves
5143 circular references requires support from object types which are
5144 ``containers'' for other objects which may also be containers. Types
5145 which do not store references to other objects, or which only store
5146 references to atomic types (such as numbers or strings), do not need
5147 to provide any explicit support for garbage collection.
5149 To create a container type, the \member{tp_flags} field of the type
5150 object must include the \constant{Py_TPFLAGS_GC} and provide an
5151 implementation of the \member{tp_traverse} handler. The computed
5152 value of the \member{tp_basicsize} field must include
5153 \constant{PyGC_HEAD_SIZE} as well. If instances of the type are
5154 mutable, a \member{tp_clear} implementation must also be provided.
5156 \begin{datadesc}{Py_TPFLAGS_GC}
5157 Objects with a type with this flag set must conform with the rules
5158 documented here. For convenience these objects will be referred to
5159 as container objects.
5162 \begin{datadesc}{PyGC_HEAD_SIZE}
5163 Extra memory needed for the garbage collector. Container objects
5164 must include this in the calculation of their tp_basicsize. If the
5165 collector is disabled at compile time then this is \code{0}.
5168 Constructors for container types must conform to two rules:
5171 \item The memory for the object must be allocated using
5172 \cfunction{PyObject_New()} or \cfunction{PyObject_VarNew()}.
5174 \item Once all the fields which may contain references to other
5175 containers are initialized, it must call
5176 \cfunction{PyObject_GC_Init()}.
5179 \begin{cfuncdesc}{void}{PyObject_GC_Init}{PyObject *op}
5180 Adds the object \var{op} to the set of container objects tracked by
5181 the collector. The collector can run at unexpected times so objects
5182 must be valid while being tracked. This should be called once all
5183 the fields followed by the \member{tp_traverse} handler become valid,
5184 usually near the end of the constructor.
5187 Similarly, the deallocator for the object must conform to a similar
5191 \item Before fields which refer to other containers are invalidated,
5192 \cfunction{PyObject_GC_Fini()} must be called.
5194 \item The object's memory must be deallocated using
5195 \cfunction{PyObject_Del()}.
5198 \begin{cfuncdesc}{void}{PyObject_GC_Fini}{PyObject *op}
5199 Remove the object \var{op} from the set of container objects tracked
5200 by the collector. Note that \cfunction{PyObject_GC_Init()} can be
5201 called again on this object to add it back to the set of tracked
5202 objects. The deallocator (\member{tp_dealloc} handler) should call
5203 this for the object before any of the fields used by the
5204 \member{tp_traverse} handler become invalid.
5206 \strong{Note:} Any container which may be referenced from another
5207 object reachable by the collector must itself be tracked by the
5208 collector, so it is generally not safe to call this function
5209 anywhere but in the object's deallocator.
5212 The \member{tp_traverse} handler accepts a function parameter of this
5215 \begin{ctypedesc}[visitproc]{int (*visitproc)(PyObject *object, void *arg)}
5216 Type of the visitor function passed to the \member{tp_traverse}
5217 handler. The function should be called with an object to traverse
5218 as \var{object} and the third parameter to the \member{tp_traverse}
5219 handler as \var{arg}.
5222 The \member{tp_traverse} handler must have the following type:
5224 \begin{ctypedesc}[traverseproc]{int (*traverseproc)(PyObject *self,
5225 visitproc visit, void *arg)}
5226 Traversal function for a container object. Implementations must
5227 call the \var{visit} function for each object directly contained by
5228 \var{self}, with the parameters to \var{visit} being the contained
5229 object and the \var{arg} value passed to the handler. If
5230 \var{visit} returns a non-zero value then an error has occurred and
5231 that value should be returned immediately.
5234 The \member{tp_clear} handler must be of the \ctype{inquiry} type, or
5235 \NULL{} if the object is immutable.
5237 \begin{ctypedesc}[inquiry]{int (*inquiry)(PyObject *self)}
5238 Drop references that may have created reference cycles. Immutable
5239 objects do not have to define this method since they can never
5240 directly create reference cycles. Note that the object must still
5241 be valid after calling this method (don't just call
5242 \cfunction{Py_DECREF()} on a reference). The collector will call
5243 this method if it detects that this object is involved in a
5248 \subsection{Example Cycle Collector Support
5249 \label{example-cycle-support}}
5251 This example shows only enough of the implementation of an extension
5252 type to show how the garbage collector support needs to be added. It
5253 shows the definition of the object structure, the
5254 \member{tp_traverse}, \member{tp_clear} and \member{tp_dealloc}
5255 implementations, the type structure, and a constructor --- the module
5256 initialization needed to export the constructor to Python is not shown
5257 as there are no special considerations there for the collector. To
5258 make this interesting, assume that the module exposes ways for the
5259 \member{container} field of the object to be modified. Note that
5260 since no checks are made on the type of the object used to initialize
5261 \member{container}, we have to assume that it may be a container.
5268 PyObject *container;
5272 my_traverse(MyObject *self, visitproc visit, void *arg)
5274 if (self->container != NULL)
5275 return visit(self->container, arg);
5281 my_clear(MyObject *self)
5283 Py_XDECREF(self->container);
5284 self->container = NULL;
5290 my_dealloc(MyObject *self)
5292 PyObject_GC_Fini((PyObject *) self);
5293 Py_XDECREF(self->container);
5299 statichere PyTypeObject
5301 PyObject_HEAD_INIT(NULL)
5304 sizeof(MyObject) + PyGC_HEAD_SIZE,
5306 (destructor)my_dealloc, /* tp_dealloc */
5312 0, /* tp_as_number */
5313 0, /* tp_as_sequence */
5314 0, /* tp_as_mapping */
5318 0, /* tp_getattro */
5319 0, /* tp_setattro */
5320 0, /* tp_as_buffer */
5321 Py_TPFLAGS_DEFAULT | Py_TPFLAGS_GC,
5323 (traverseproc)my_traverse, /* tp_traverse */
5324 (inquiry)my_clear, /* tp_clear */
5325 0, /* tp_richcompare */
5326 0, /* tp_weaklistoffset */
5329 /* This constructor should be made accessible from Python. */
5331 new_object(PyObject *unused, PyObject *args)
5333 PyObject *container = NULL;
5334 MyObject *result = NULL;
5336 if (PyArg_ParseTuple(args, "|O:new_object", &container))
{
5337 result = PyObject_New(MyObject, &MyObject_Type);
5338 if (result != NULL)
{
5339 result->container = container;
5343 return (PyObject *) result;
5348 % \chapter{Debugging \label{debugging}}
5350 % XXX Explain Py_DEBUG, Py_TRACE_REFS, Py_REF_DEBUG.
5354 \chapter{Reporting Bugs
}
5355 \input{reportingbugs
}
5357 \chapter{History and License
}
5360 \input{api.ind
} % Index -- must be last