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, ranging
1135 from helping C code be more portable across platforms, using Python
1136 modules from C, and parsing function arguments and constructing Python
1137 values from C values.
1140 \section{Operating System Utilities
\label{os
}}
1142 \begin{cfuncdesc
}{int
}{Py_FdIsInteractive
}{FILE *fp, char *filename
}
1143 Return true (nonzero) if the standard I/O file
\var{fp
} with name
1144 \var{filename
} is deemed interactive. This is the case for files for
1145 which
\samp{isatty(fileno(
\var{fp
}))
} is true. If the global flag
1146 \cdata{Py_InteractiveFlag
} is true, this function also returns true if
1147 the
\var{filename
} pointer is
\NULL{} or if the name is equal to one of
1148 the strings
\code{'<stdin>'
} or
\code{'???'
}.
1151 \begin{cfuncdesc
}{long
}{PyOS_GetLastModificationTime
}{char *filename
}
1152 Return the time of last modification of the file
\var{filename
}.
1153 The result is encoded in the same way as the timestamp returned by
1154 the standard C library function
\cfunction{time()
}.
1157 \begin{cfuncdesc
}{void
}{PyOS_AfterFork
}{}
1158 Function to update some internal state after a process fork; this
1159 should be called in the new process if the Python interpreter will
1160 continue to be used. If a new executable is loaded into the new
1161 process, this function does not need to be called.
1164 \begin{cfuncdesc
}{int
}{PyOS_CheckStack
}{}
1165 Return true when the interpreter runs out of stack space. This is a
1166 reliable check, but is only available when
\code{USE_STACKCHECK
} is
1167 defined (currently on Windows using the Microsoft Visual C++ compiler
1168 and on the Macintosh).
\code{USE_CHECKSTACK
} will be defined
1169 automatically; you should never change the definition in your own
1173 \begin{cfuncdesc
}{PyOS_sighandler_t
}{PyOS_getsig
}{int i
}
1174 Return the current signal handler for signal
\var{i
}.
1175 This is a thin wrapper around either
\cfunction{sigaction
} or
1176 \cfunction{signal
}. Do not call those functions directly!
1177 \ctype{PyOS_sighandler_t
} is a typedef alias for
\ctype{void
(*)(int)}.
1180 \begin{cfuncdesc}{PyOS_sighandler_t}{PyOS_setsig}{int i, PyOS_sighandler_t h}
1181 Set the signal handler for signal \var{i} to be \var{h};
1182 return the old signal handler.
1183 This is a thin wrapper around either \cfunction{sigaction} or
1184 \cfunction{signal}. Do not call those functions directly!
1185 \ctype{PyOS_sighandler_t} is a typedef alias for \ctype{void (*)(int)}.
1189 \section{Process Control \label{processControl}}
1191 \begin{cfuncdesc}{void}{Py_FatalError}{char *message}
1192 Print a fatal error message and kill the process. No cleanup is
1193 performed. This function should only be invoked when a condition is
1194 detected that would make it dangerous to continue using the Python
1195 interpreter; e.g., when the object administration appears to be
1196 corrupted. On \UNIX{}, the standard C library function
1197 \cfunction{abort()}\ttindex{abort()} is called which will attempt to
1198 produce a \file{core} file.
1201 \begin{cfuncdesc}{void}{Py_Exit}{int status}
1202 Exit the current process. This calls
1203 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()} and
1204 then calls the standard C library function
1205 \code{exit(\var{status})}\ttindex{exit()}.
1208 \begin{cfuncdesc}{int}{Py_AtExit}{void (*func) ()}
1209 Register a cleanup function to be called by
1210 \cfunction{Py_Finalize()}\ttindex{Py_Finalize()}.
1211 The cleanup function will be called with no arguments and should
1212 return no value. At most 32 \index{cleanup functions}cleanup
1213 functions can be registered.
1214 When the registration is successful, \cfunction{Py_AtExit()} returns
1215 \code{0}; on failure, it returns \code{-1}. The cleanup function
1216 registered last is called first. Each cleanup function will be called
1217 at most once. Since Python's internal finallization will have
1218 completed before the cleanup function, no Python APIs should be called
1223 \section{Importing Modules \label{importing}}
1225 \begin{cfuncdesc}{PyObject*}{PyImport_ImportModule}{char *name}
1226 This is a simplified interface to
1227 \cfunction{PyImport_ImportModuleEx()} below, leaving the
1228 \var{globals} and \var{locals} arguments set to \NULL{}. When the
1229 \var{name} argument contains a dot (when it specifies a
1230 submodule of a package), the \var{fromlist} argument is set to the
1231 list \code{['*']} so that the return value is the named module rather
1232 than the top-level package containing it as would otherwise be the
1233 case. (Unfortunately, this has an additional side effect when
1234 \var{name} in fact specifies a subpackage instead of a submodule: the
1235 submodules specified in the package's \code{__all__} variable are
1236 \index{package variable!\code{__all__}}
1237 \withsubitem{(package variable)}{\ttindex{__all__}}loaded.) Return a
1238 new reference to the imported module, or
1239 \NULL{} with an exception set on failure (the module may still be
1240 created in this case --- examine \code{sys.modules} to find out).
1241 \withsubitem{(in module sys)}{\ttindex{modules}}
1244 \begin{cfuncdesc}{PyObject*}{PyImport_ImportModuleEx}{char *name,
1245 PyObject *globals, PyObject *locals, PyObject *fromlist}
1246 Import a module. This is best described by referring to the built-in
1247 Python function \function{__import__()}\bifuncindex{__import__}, as
1248 the standard \function{__import__()} function calls this function
1251 The return value is a new reference to the imported module or
1252 top-level package, or \NULL{} with an exception set on failure
1253 (the module may still be created in this case). Like for
1254 \function{__import__()}, the return value when a submodule of a
1255 package was requested is normally the top-level package, unless a
1256 non-empty \var{fromlist} was given.
1259 \begin{cfuncdesc}{PyObject*}{PyImport_Import}{PyObject *name}
1260 This is a higher-level interface that calls the current ``import hook
1261 function''. It invokes the \function{__import__()} function from the
1262 \code{__builtins__} of the current globals. This means that the
1263 import is done using whatever import hooks are installed in the
1264 current environment, e.g. by \module{rexec}\refstmodindex{rexec} or
1265 \module{ihooks}\refstmodindex{ihooks}.
1268 \begin{cfuncdesc}{PyObject*}{PyImport_ReloadModule}{PyObject *m}
1269 Reload a module. This is best described by referring to the built-in
1270 Python function \function{reload()}\bifuncindex{reload}, as the standard
1271 \function{reload()} function calls this function directly. Return a
1272 new reference to the reloaded module, or \NULL{} with an exception set
1273 on failure (the module still exists in this case).
1276 \begin{cfuncdesc}{PyObject*}{PyImport_AddModule}{char *name}
1277 Return the module object corresponding to a module name. The
1278 \var{name} argument may be of the form \code{package.module}). First
1279 check the modules dictionary if there's one there, and if not, create
1280 a new one and insert in in the modules dictionary.
1281 Warning: this function does not load or import the module; if the
1282 module wasn't already loaded, you will get an empty module object.
1283 Use \cfunction{PyImport_ImportModule()} or one of its variants to
1285 Return \NULL{} with an exception set on failure.
1288 \begin{cfuncdesc}{PyObject*}{PyImport_ExecCodeModule}{char *name, PyObject *co}
1289 Given a module name (possibly of the form \code{package.module}) and a
1290 code object read from a Python bytecode file or obtained from the
1291 built-in function \function{compile()}\bifuncindex{compile}, load the
1292 module. Return a new reference to the module object, or \NULL{} with
1293 an exception set if an error occurred (the module may still be created
1294 in this case). (This function would reload the module if it was
1298 \begin{cfuncdesc}{long}{PyImport_GetMagicNumber}{}
1299 Return the magic number for Python bytecode files (a.k.a.
1300 \file{.pyc} and \file{.pyo} files). The magic number should be
1301 present in the first four bytes of the bytecode file, in little-endian
1305 \begin{cfuncdesc}{PyObject*}{PyImport_GetModuleDict}{}
1306 Return the dictionary used for the module administration
1307 (a.k.a. \code{sys.modules}). Note that this is a per-interpreter
1311 \begin{cfuncdesc}{void}{_PyImport_Init}{}
1312 Initialize the import mechanism. For internal use only.
1315 \begin{cfuncdesc}{void}{PyImport_Cleanup}{}
1316 Empty the module table. For internal use only.
1319 \begin{cfuncdesc}{void}{_PyImport_Fini}{}
1320 Finalize the import mechanism. For internal use only.
1323 \begin{cfuncdesc}{PyObject*}{_PyImport_FindExtension}{char *, char *}
1324 For internal use only.
1327 \begin{cfuncdesc}{PyObject*}{_PyImport_FixupExtension}{char *, char *}
1328 For internal use only.
1331 \begin{cfuncdesc}{int}{PyImport_ImportFrozenModule}{char *name}
1332 Load a frozen module named \var{name}. Return \code{1} for success,
1333 \code{0} if the module is not found, and \code{-1} with an exception
1334 set if the initialization failed. To access the imported module on a
1335 successful load, use \cfunction{PyImport_ImportModule()}.
1336 (Note the misnomer --- this function would reload the module if it was
1340 \begin{ctypedesc}[_frozen]{struct _frozen}
1341 This is the structure type definition for frozen module descriptors,
1342 as generated by the \program{freeze}\index{freeze utility} utility
1343 (see \file{Tools/freeze/} in the Python source distribution). Its
1344 definition, found in \file{Include/import.h}, is:
1349 unsigned char *code;
1355 \begin{cvardesc}{struct _frozen*}{PyImport_FrozenModules}
1356 This pointer is initialized to point to an array of \ctype{struct
1357 _frozen} records, terminated by one whose members are all
1358 \NULL{} or zero. When a frozen module is imported, it is searched in
1359 this table. Third-party code could play tricks with this to provide a
1360 dynamically created collection of frozen modules.
1363 \begin{cfuncdesc}{int}{PyImport_AppendInittab}{char *name,
1364 void (*initfunc)(void)}
1365 Add a single module to the existing table of built-in modules. This
1366 is a convenience wrapper around \cfunction{PyImport_ExtendInittab()},
1367 returning \code{-1} if the table could not be extended. The new
1368 module can be imported by the name \var{name}, and uses the function
1369 \var{initfunc} as the initialization function called on the first
1370 attempted import. This should be called before
1371 \cfunction{Py_Initialize()}.
1374 \begin{ctypedesc}[_inittab]{struct _inittab}
1375 Structure describing a single entry in the list of built-in modules.
1376 Each of these structures gives the name and initialization function
1377 for a module built into the interpreter. Programs which embed Python
1378 may use an array of these structures in conjunction with
1379 \cfunction{PyImport_ExtendInittab()} to provide additional built-in
1380 modules. The structure is defined in \file{Include/import.h} as:
1385 void (*initfunc)(void);
1390 \begin{cfuncdesc}{int}{PyImport_ExtendInittab}{struct _inittab *newtab}
1391 Add a collection of modules to the table of built-in modules. The
1392 \var{newtab} array must end with a sentinel entry which contains
1393 \NULL{} for the \member{name} field; failure to provide the sentinel
1394 value can result in a memory fault. Returns \code{0} on success or
1395 \code{-1} if insufficient memory could be allocated to extend the
1396 internal table. In the event of failure, no modules are added to the
1397 internal table. This should be called before
1398 \cfunction{Py_Initialize()}.
1402 \section{Parsing arguements and building values
1403 \label{arg-parsing}}
1405 These functions are useful when creating your own extensions functions
1406 and methods. Additional information and examples are available in
1407 \citetitle[../ext/ext.html]{Extending and Embedding the Python
1410 \begin{cfuncdesc}{int}{PyArg_ParseTuple}{PyObject *args, char *format,
1412 Parse the parameters of a function that takes only positional
1413 parameters into local variables. Returns true on success; on
1414 failure, it returns false and raises the appropriate exception. See
1415 \citetitle[../ext/parseTuple.html]{Extending and Embedding the
1416 Python Interpreter} for more information.
1419 \begin{cfuncdesc}{int}{PyArg_ParseTupleAndKeywords}{PyObject *args,
1420 PyObject *kw, char *format, char *keywords[],
1422 Parse the parameters of a function that takes both positional and
1423 keyword parameters into local variables. Returns true on success;
1424 on failure, it returns false and raises the appropriate exception.
1425 See \citetitle[../ext/parseTupleAndKeywords.html]{Extending and
1426 Embedding the Python Interpreter} for more information.
1429 \begin{cfuncdesc}{int}{PyArg_Parse}{PyObject *args, char *format,
1431 Function used to deconstruct the argument lists of ``old-style''
1432 functions --- these are functions which use the
1433 \constant{METH_OLDARGS} parameter parsing method. This is not
1434 recommended for use in parameter parsing in new code, and most code
1435 in the standard interpreter has been modified to no longer use this
1436 for that purpose. It does remain a convenient way to decompose
1437 other tuples, however, and may continue to be used for that
1441 \begin{cfuncdesc}{PyObject*}{Py_BuildValue}{char *format,
1443 Create a new value based on a format string similar to those
1444 accepted by the \cfunction{PyArg_Parse*()} family of functions and a
1445 sequence of values. Returns the value or \NULL{} in the case of an
1446 error; an exception will be raised if \NULL{} is returned. For more
1447 information on the format string and additional parameters, see
1448 \citetitle[../ext/buildValue.html]{Extending and Embedding the
1449 Python Interpreter}.
1454 \chapter{Abstract Objects Layer \label{abstract}}
1456 The functions in this chapter interact with Python objects regardless
1457 of their type, or with wide classes of object types (e.g. all
1458 numerical types, or all sequence types). When used on object types
1459 for which they do not apply, they will raise a Python exception.
1461 \section{Object Protocol \label{object}}
1463 \begin{cfuncdesc}{int}{PyObject_Print}{PyObject *o, FILE *fp, int flags}
1464 Print an object \var{o}, on file \var{fp}. Returns \code{-1} on error.
1465 The flags argument is used to enable certain printing options. The
1466 only option currently supported is \constant{Py_PRINT_RAW}; if given,
1467 the \function{str()} of the object is written instead of the
1471 \begin{cfuncdesc}{int}{PyObject_HasAttrString}{PyObject *o, char *attr_name}
1472 Returns \code{1} if \var{o} has the attribute \var{attr_name}, and
1473 \code{0} otherwise. This is equivalent to the Python expression
1474 \samp{hasattr(\var{o}, \var{attr_name})}.
1475 This function always succeeds.
1478 \begin{cfuncdesc}{PyObject*}{PyObject_GetAttrString}{PyObject *o,
1480 Retrieve an attribute named \var{attr_name} from object \var{o}.
1481 Returns the attribute value on success, or \NULL{} on failure.
1482 This is the equivalent of the Python expression
1483 \samp{\var{o}.\var{attr_name}}.
1487 \begin{cfuncdesc}{int}{PyObject_HasAttr}{PyObject *o, PyObject *attr_name}
1488 Returns \code{1} if \var{o} has the attribute \var{attr_name}, and
1489 \code{0} otherwise. This is equivalent to the Python expression
1490 \samp{hasattr(\var{o}, \var{attr_name})}.
1491 This function always succeeds.
1495 \begin{cfuncdesc}{PyObject*}{PyObject_GetAttr}{PyObject *o,
1496 PyObject *attr_name}
1497 Retrieve an attribute named \var{attr_name} from object \var{o}.
1498 Returns the attribute value on success, or \NULL{} on failure.
1499 This is the equivalent of the Python expression
1500 \samp{\var{o}.\var{attr_name}}.
1504 \begin{cfuncdesc}{int}{PyObject_SetAttrString}{PyObject *o,
1505 char *attr_name, PyObject *v}
1506 Set the value of the attribute named \var{attr_name}, for object
1507 \var{o}, to the value \var{v}. Returns \code{-1} on failure. This is
1508 the equivalent of the Python statement \samp{\var{o}.\var{attr_name} =
1513 \begin{cfuncdesc}{int}{PyObject_SetAttr}{PyObject *o,
1514 PyObject *attr_name, PyObject *v}
1515 Set the value of the attribute named \var{attr_name}, for
1517 to the value \var{v}. Returns \code{-1} on failure. This is
1518 the equivalent of the Python statement \samp{\var{o}.\var{attr_name} =
1523 \begin{cfuncdesc}{int}{PyObject_DelAttrString}{PyObject *o, char *attr_name}
1524 Delete attribute named \var{attr_name}, for object \var{o}. Returns
1525 \code{-1} on failure. This is the equivalent of the Python
1526 statement: \samp{del \var{o}.\var{attr_name}}.
1530 \begin{cfuncdesc}{int}{PyObject_DelAttr}{PyObject *o, PyObject *attr_name}
1531 Delete attribute named \var{attr_name}, for object \var{o}. Returns
1532 \code{-1} on failure. This is the equivalent of the Python
1533 statement \samp{del \var{o}.\var{attr_name}}.
1537 \begin{cfuncdesc}{int}{PyObject_Cmp}{PyObject *o1, PyObject *o2, int *result}
1538 Compare the values of \var{o1} and \var{o2} using a routine provided
1539 by \var{o1}, if one exists, otherwise with a routine provided by
1540 \var{o2}. The result of the comparison is returned in \var{result}.
1541 Returns \code{-1} on failure. This is the equivalent of the Python
1542 statement\bifuncindex{cmp} \samp{\var{result} = cmp(\var{o1}, \var{o2})}.
1546 \begin{cfuncdesc}{int}{PyObject_Compare}{PyObject *o1, PyObject *o2}
1547 Compare the values of \var{o1} and \var{o2} using a routine provided
1548 by \var{o1}, if one exists, otherwise with a routine provided by
1549 \var{o2}. Returns the result of the comparison on success. On error,
1550 the value returned is undefined; use \cfunction{PyErr_Occurred()} to
1551 detect an error. This is equivalent to the Python
1552 expression\bifuncindex{cmp} \samp{cmp(\var{o1}, \var{o2})}.
1556 \begin{cfuncdesc}{PyObject*}{PyObject_Repr}{PyObject *o}
1557 Compute a string representation of object \var{o}. Returns the
1558 string representation on success, \NULL{} on failure. This is
1559 the equivalent of the Python expression \samp{repr(\var{o})}.
1560 Called by the \function{repr()}\bifuncindex{repr} built-in function
1561 and by reverse quotes.
1565 \begin{cfuncdesc}{PyObject*}{PyObject_Str}{PyObject *o}
1566 Compute a string representation of object \var{o}. Returns the
1567 string representation on success, \NULL{} on failure. This is
1568 the equivalent of the Python expression \samp{str(\var{o})}.
1569 Called by the \function{str()}\bifuncindex{str} built-in function and
1570 by the \keyword{print} statement.
1574 \begin{cfuncdesc}{PyObject*}{PyObject_Unicode}{PyObject *o}
1575 Compute a Unicode string representation of object \var{o}. Returns the
1576 Unicode string representation on success, \NULL{} on failure. This is
1577 the equivalent of the Python expression \samp{unistr(\var{o})}.
1578 Called by the \function{unistr()}\bifuncindex{unistr} built-in function.
1581 \begin{cfuncdesc}{int}{PyObject_IsInstance}{PyObject *inst, PyObject *cls}
1582 Return \code{1} if \var{inst} is an instance of the class \var{cls} or
1583 a subclass of \var{cls}. If \var{cls} is a type object rather than a
1584 class object, \cfunction{PyObject_IsInstance()} returns \code{1} if
1585 \var{inst} is of type \var{cls}. If \var{inst} is not a class
1586 instance and \var{cls} is neither a type object or class object,
1587 \var{inst} must have a \member{__class__} attribute --- the class
1588 relationship of the value of that attribute with \var{cls} will be
1589 used to determine the result of this function.
1593 Subclass determination is done in a fairly straightforward way, but
1594 includes a wrinkle that implementors of extensions to the class system
1595 may want to be aware of. If \class{A} and \class{B} are class
1596 objects, \class{B} is a subclass of \class{A} if it inherits from
1597 \class{A} either directly or indirectly. If either is not a class
1598 object, a more general mechanism is used to determine the class
1599 relationship of the two objects. When testing if \var{B} is a
1600 subclass of \var{A}, if \var{A} is \var{B},
1601 \cfunction{PyObject_IsSubclass()} returns true. If \var{A} and
1602 \var{B} are different objects, \var{B}'s \member{__bases__} attribute
1603 is searched in a depth-first fashion for \var{A} --- the presence of
1604 the \member{__bases__} attribute is considered sufficient for this
1607 \begin{cfuncdesc}{int}{PyObject_IsSubclass}{PyObject *derived,
1609 Returns \code{1} if the class \var{derived} is identical to or derived
1610 from the class \var{cls}, otherwise returns \code{0}. In case of an
1611 error, returns \code{-1}. If either \var{derived} or \var{cls} is not
1612 an actual class object, this function uses the generic algorithm
1618 \begin{cfuncdesc}{int}{PyCallable_Check}{PyObject *o}
1619 Determine if the object \var{o} is callable. Return \code{1} if the
1620 object is callable and \code{0} otherwise.
1621 This function always succeeds.
1625 \begin{cfuncdesc}{PyObject*}{PyObject_CallObject}{PyObject *callable_object,
1627 Call a callable Python object \var{callable_object}, with
1628 arguments given by the tuple \var{args}. If no arguments are
1629 needed, then \var{args} may be \NULL{}. Returns the result of the
1630 call on success, or \NULL{} on failure. This is the equivalent
1631 of the Python expression \samp{apply(\var{callable_object},
1632 \var{args})} or \samp{\var{callable_object}(*\var{args})}.
1636 \begin{cfuncdesc}{PyObject*}{PyObject_CallFunction}{PyObject *callable_object,
1638 Call a callable Python object \var{callable_object}, with a
1639 variable number of C arguments. The C arguments are described
1640 using a \cfunction{Py_BuildValue()} style format string. The format may
1641 be \NULL{}, indicating that no arguments are provided. Returns the
1642 result of the call on success, or \NULL{} on failure. This is
1643 the equivalent of the Python expression
1644 \samp{apply(\var{callable_object}\var{args})} or
1645 \samp{\var{callable_object}(*\var{args})}.
1650 \begin{cfuncdesc}{PyObject*}{PyObject_CallMethod}{PyObject *o,
1651 char *method, char *format, ...}
1652 Call the method named \var{m} of object \var{o} with a variable number
1653 of C arguments. The C arguments are described by a
1654 \cfunction{Py_BuildValue()} format string. The format may be \NULL{},
1655 indicating that no arguments are provided. Returns the result of the
1656 call on success, or \NULL{} on failure. This is the equivalent of the
1657 Python expression \samp{\var{o}.\var{method}(\var{args})}.
1658 Note that special method names, such as \method{__add__()},
1659 \method{__getitem__()}, and so on are not supported. The specific
1660 abstract-object routines for these must be used.
1664 \begin{cfuncdesc}{int}{PyObject_Hash}{PyObject *o}
1665 Compute and return the hash value of an object \var{o}. On
1666 failure, return \code{-1}. This is the equivalent of the Python
1667 expression \samp{hash(\var{o})}.\bifuncindex{hash}
1671 \begin{cfuncdesc}{int}{PyObject_IsTrue}{PyObject *o}
1672 Returns \code{1} if the object \var{o} is considered to be true, and
1673 \code{0} otherwise. This is equivalent to the Python expression
1674 \samp{not not \var{o}}.
1675 This function always succeeds.
1679 \begin{cfuncdesc}{PyObject*}{PyObject_Type}{PyObject *o}
1680 On success, returns a type object corresponding to the object
1681 type of object \var{o}. On failure, returns \NULL{}. This is
1682 equivalent to the Python expression \samp{type(\var{o})}.
1686 \begin{cfuncdesc}{int}{PyObject_Length}{PyObject *o}
1687 Return the length of object \var{o}. If the object \var{o} provides
1688 both sequence and mapping protocols, the sequence length is
1689 returned. On error, \code{-1} is returned. This is the equivalent
1690 to the Python expression \samp{len(\var{o})}.\bifuncindex{len}
1694 \begin{cfuncdesc}{PyObject*}{PyObject_GetItem}{PyObject *o, PyObject *key}
1695 Return element of \var{o} corresponding to the object \var{key} or
1696 \NULL{} on failure. This is the equivalent of the Python expression
1697 \samp{\var{o}[\var{key}]}.
1701 \begin{cfuncdesc}{int}{PyObject_SetItem}{PyObject *o,
1702 PyObject *key, PyObject *v}
1703 Map the object \var{key} to the value \var{v}.
1704 Returns \code{-1} on failure. This is the equivalent
1705 of the Python statement \samp{\var{o}[\var{key}] = \var{v}}.
1709 \begin{cfuncdesc}{int}{PyObject_DelItem}{PyObject *o, PyObject *key}
1710 Delete the mapping for \var{key} from \var{o}. Returns \code{-1} on
1711 failure. This is the equivalent of the Python statement \samp{del
1712 \var{o}[\var{key}]}.
1715 \begin{cfuncdesc}{int}{PyObject_AsFileDescriptor}{PyObject *o}
1716 Derives a file-descriptor from a Python object. If the object
1717 is an integer or long integer, its value is returned. If not, the
1718 object's \method{fileno()} method is called if it exists; the method
1719 must return an integer or long integer, which is returned as the file
1720 descriptor value. Returns \code{-1} on failure.
1724 \section{Number Protocol \label{number}}
1726 \begin{cfuncdesc}{int}{PyNumber_Check}{PyObject *o}
1727 Returns \code{1} if the object \var{o} provides numeric protocols, and
1729 This function always succeeds.
1733 \begin{cfuncdesc}{PyObject*}{PyNumber_Add}{PyObject *o1, PyObject *o2}
1734 Returns the result of adding \var{o1} and \var{o2}, or \NULL{} on
1735 failure. This is the equivalent of the Python expression
1736 \samp{\var{o1} + \var{o2}}.
1740 \begin{cfuncdesc}{PyObject*}{PyNumber_Subtract}{PyObject *o1, PyObject *o2}
1741 Returns the result of subtracting \var{o2} from \var{o1}, or
1742 \NULL{} on failure. This is the equivalent of the Python expression
1743 \samp{\var{o1} - \var{o2}}.
1747 \begin{cfuncdesc}{PyObject*}{PyNumber_Multiply}{PyObject *o1, PyObject *o2}
1748 Returns the result of multiplying \var{o1} and \var{o2}, or \NULL{} on
1749 failure. This is the equivalent of the Python expression
1750 \samp{\var{o1} * \var{o2}}.
1754 \begin{cfuncdesc}{PyObject*}{PyNumber_Divide}{PyObject *o1, PyObject *o2}
1755 Returns the result of dividing \var{o1} by \var{o2}, or \NULL{} on
1757 This is the equivalent of the Python expression \samp{\var{o1} /
1762 \begin{cfuncdesc}{PyObject*}{PyNumber_FloorDivide}{PyObject *o1, PyObject *o2}
1763 Return the floor of \var{o1} divided by \var{o2}, or \NULL{} on
1764 failure. This is equivalent to the ``classic'' division of integers.
1769 \begin{cfuncdesc}{PyObject*}{PyNumber_TrueDivide}{PyObject *o1, PyObject *o2}
1770 Return a reasonable approximation for the mathematical value of
1771 \var{o1} divided by \var{o2}, or \NULL{} on failure. The return value
1772 is ``approximate'' because binary floating point numbers are
1773 approximate; it is not possible to represent all real numbers in base
1774 two. This function can return a floating point value when passed two
1780 \begin{cfuncdesc}{PyObject*}{PyNumber_Remainder}{PyObject *o1, PyObject *o2}
1781 Returns the remainder of dividing \var{o1} by \var{o2}, or \NULL{} on
1782 failure. This is the equivalent of the Python expression
1783 \samp{\var{o1} \%\ \var{o2}}.
1787 \begin{cfuncdesc}{PyObject*}{PyNumber_Divmod}{PyObject *o1, PyObject *o2}
1788 See the built-in function \function{divmod()}\bifuncindex{divmod}.
1789 Returns \NULL{} on failure. This is the equivalent of the Python
1790 expression \samp{divmod(\var{o1}, \var{o2})}.
1794 \begin{cfuncdesc}{PyObject*}{PyNumber_Power}{PyObject *o1,
1795 PyObject *o2, PyObject *o3}
1796 See the built-in function \function{pow()}\bifuncindex{pow}. Returns
1797 \NULL{} on failure. This is the equivalent of the Python expression
1798 \samp{pow(\var{o1}, \var{o2}, \var{o3})}, where \var{o3} is optional.
1799 If \var{o3} is to be ignored, pass \cdata{Py_None} in its place
1800 (passing \NULL{} for \var{o3} would cause an illegal memory access).
1804 \begin{cfuncdesc}{PyObject*}{PyNumber_Negative}{PyObject *o}
1805 Returns the negation of \var{o} on success, or \NULL{} on failure.
1806 This is the equivalent of the Python expression \samp{-\var{o}}.
1810 \begin{cfuncdesc}{PyObject*}{PyNumber_Positive}{PyObject *o}
1811 Returns \var{o} on success, or \NULL{} on failure.
1812 This is the equivalent of the Python expression \samp{+\var{o}}.
1816 \begin{cfuncdesc}{PyObject*}{PyNumber_Absolute}{PyObject *o}
1817 Returns the absolute value of \var{o}, or \NULL{} on failure. This is
1818 the equivalent of the Python expression \samp{abs(\var{o})}.
1823 \begin{cfuncdesc}{PyObject*}{PyNumber_Invert}{PyObject *o}
1824 Returns the bitwise negation of \var{o} on success, or \NULL{} on
1825 failure. This is the equivalent of the Python expression
1830 \begin{cfuncdesc}{PyObject*}{PyNumber_Lshift}{PyObject *o1, PyObject *o2}
1831 Returns the result of left shifting \var{o1} by \var{o2} on success,
1832 or \NULL{} on failure. This is the equivalent of the Python
1833 expression \samp{\var{o1} <\code{<} \var{o2}}.
1837 \begin{cfuncdesc}{PyObject*}{PyNumber_Rshift}{PyObject *o1, PyObject *o2}
1838 Returns the result of right shifting \var{o1} by \var{o2} on success,
1839 or \NULL{} on failure. This is the equivalent of the Python
1840 expression \samp{\var{o1} >\code{>} \var{o2}}.
1844 \begin{cfuncdesc}{PyObject*}{PyNumber_And}{PyObject *o1, PyObject *o2}
1845 Returns the ``bitwise and'' of \var{o2} and \var{o2} on success and
1846 \NULL{} on failure. This is the equivalent of the Python expression
1847 \samp{\var{o1} \&\ \var{o2}}.
1851 \begin{cfuncdesc}{PyObject*}{PyNumber_Xor}{PyObject *o1, PyObject *o2}
1852 Returns the ``bitwise exclusive or'' of \var{o1} by \var{o2} on success,
1853 or \NULL{} on failure. This is the equivalent of the Python
1854 expression \samp{\var{o1} \textasciicircum{} \var{o2}}.
1857 \begin{cfuncdesc}{PyObject*}{PyNumber_Or}{PyObject *o1, PyObject *o2}
1858 Returns the ``bitwise or'' of \var{o1} and \var{o2} on success, or
1859 \NULL{} on failure. This is the equivalent of the Python expression
1860 \samp{\var{o1} | \var{o2}}.
1864 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceAdd}{PyObject *o1, PyObject *o2}
1865 Returns the result of adding \var{o1} and \var{o2}, or \NULL{} on
1866 failure. The operation is done \emph{in-place} when \var{o1} supports
1867 it. This is the equivalent of the Python statement \samp{\var{o1} +=
1872 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceSubtract}{PyObject *o1,
1874 Returns the result of subtracting \var{o2} from \var{o1}, or
1875 \NULL{} on failure. The operation is done \emph{in-place} when
1876 \var{o1} supports it. This is the equivalent of the Python statement
1877 \samp{\var{o1} -= \var{o2}}.
1881 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceMultiply}{PyObject *o1,
1883 Returns the result of multiplying \var{o1} and \var{o2}, or \NULL{} on
1884 failure. The operation is done \emph{in-place} when \var{o1} supports it.
1885 This is the equivalent of the Python statement \samp{\var{o1} *= \var{o2}}.
1889 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceDivide}{PyObject *o1,
1891 Returns the result of dividing \var{o1} by \var{o2}, or \NULL{} on
1892 failure. The operation is done \emph{in-place} when \var{o1} supports
1893 it. This is the equivalent of the Python statement \samp{\var{o1} /=
1898 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceFloorDivide}{PyObject *o1,
1900 Returns the mathematical of dividing \var{o1} by \var{o2}, or \NULL{}
1901 on failure. The operation is done \emph{in-place} when \var{o1}
1902 supports it. This is the equivalent of the Python statement
1903 \samp{\var{o1} //= \var{o2}}.
1908 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceTrueDivide}{PyObject *o1,
1910 Return a reasonable approximation for the mathematical value of
1911 \var{o1} divided by \var{o2}, or \NULL{} on failure. The return value
1912 is ``approximate'' because binary floating point numbers are
1913 approximate; it is not possible to represent all real numbers in base
1914 two. This function can return a floating point value when passed two
1915 integers. The operation is done \emph{in-place} when \var{o1}
1921 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceRemainder}{PyObject *o1,
1923 Returns the remainder of dividing \var{o1} by \var{o2}, or \NULL{} on
1924 failure. The operation is done \emph{in-place} when \var{o1} supports it.
1925 This is the equivalent of the Python statement \samp{\var{o1} \%= \var{o2}}.
1929 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlacePower}{PyObject *o1,
1930 PyObject *o2, PyObject *o3}
1931 See the built-in function \function{pow()}.\bifuncindex{pow} Returns
1932 \NULL{} on failure. The operation is done \emph{in-place} when
1933 \var{o1} supports it. This is the equivalent of the Python statement
1934 \samp{\var{o1} **= \var{o2}} when o3 is \cdata{Py_None}, or an
1935 in-place variant of \samp{pow(\var{o1}, \var{o2}, \var{o3})}
1936 otherwise. If \var{o3} is to be ignored, pass \cdata{Py_None} in its
1937 place (passing \NULL{} for \var{o3} would cause an illegal memory
1941 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceLshift}{PyObject *o1,
1943 Returns the result of left shifting \var{o1} by \var{o2} on success,
1944 or \NULL{} on failure. The operation is done \emph{in-place} when
1945 \var{o1} supports it. This is the equivalent of the Python statement
1946 \samp{\var{o1} <\code{<=} \var{o2}}.
1950 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceRshift}{PyObject *o1,
1952 Returns the result of right shifting \var{o1} by \var{o2} on success,
1953 or \NULL{} on failure. The operation is done \emph{in-place} when
1954 \var{o1} supports it. This is the equivalent of the Python statement
1955 \samp{\var{o1} >\code{>=} \var{o2}}.
1959 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceAnd}{PyObject *o1, PyObject *o2}
1960 Returns the ``bitwise and'' of \var{o1} and \var{o2} on success
1961 and \NULL{} on failure. The operation is done \emph{in-place} when
1962 \var{o1} supports it. This is the equivalent of the Python statement
1963 \samp{\var{o1} \&= \var{o2}}.
1967 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceXor}{PyObject *o1, PyObject *o2}
1968 Returns the ``bitwise exclusive or'' of \var{o1} by \var{o2} on
1969 success, or \NULL{} on failure. The operation is done \emph{in-place}
1970 when \var{o1} supports it. This is the equivalent of the Python
1971 statement \samp{\var{o1} \textasciicircum= \var{o2}}.
1974 \begin{cfuncdesc}{PyObject*}{PyNumber_InPlaceOr}{PyObject *o1, PyObject *o2}
1975 Returns the ``bitwise or'' of \var{o1} and \var{o2} on success, or
1976 \NULL{} on failure. The operation is done \emph{in-place} when
1977 \var{o1} supports it. This is the equivalent of the Python statement
1978 \samp{\var{o1} |= \var{o2}}.
1981 \begin{cfuncdesc}{int}{PyNumber_Coerce}{PyObject **p1, PyObject **p2}
1982 This function takes the addresses of two variables of type
1983 \ctype{PyObject*}. If the objects pointed to by \code{*\var{p1}} and
1984 \code{*\var{p2}} have the same type, increment their reference count
1985 and return \code{0} (success). If the objects can be converted to a
1986 common numeric type, replace \code{*p1} and \code{*p2} by their
1987 converted value (with 'new' reference counts), and return \code{0}.
1988 If no conversion is possible, or if some other error occurs, return
1989 \code{-1} (failure) and don't increment the reference counts. The
1990 call \code{PyNumber_Coerce(\&o1, \&o2)} is equivalent to the Python
1991 statement \samp{\var{o1}, \var{o2} = coerce(\var{o1}, \var{o2})}.
1992 \bifuncindex{coerce}
1995 \begin{cfuncdesc}{PyObject*}{PyNumber_Int}{PyObject *o}
1996 Returns the \var{o} converted to an integer object on success, or
1997 \NULL{} on failure. This is the equivalent of the Python
1998 expression \samp{int(\var{o})}.\bifuncindex{int}
2001 \begin{cfuncdesc}{PyObject*}{PyNumber_Long}{PyObject *o}
2002 Returns the \var{o} converted to a long integer object on success,
2003 or \NULL{} on failure. This is the equivalent of the Python
2004 expression \samp{long(\var{o})}.\bifuncindex{long}
2007 \begin{cfuncdesc}{PyObject*}{PyNumber_Float}{PyObject *o}
2008 Returns the \var{o} converted to a float object on success, or
2009 \NULL{} on failure. This is the equivalent of the Python expression
2010 \samp{float(\var{o})}.\bifuncindex{float}
2014 \section{Sequence Protocol \label{sequence}}
2016 \begin{cfuncdesc}{int}{PySequence_Check}{PyObject *o}
2017 Return \code{1} if the object provides sequence protocol, and
2018 \code{0} otherwise. This function always succeeds.
2021 \begin{cfuncdesc}{int}{PySequence_Size}{PyObject *o}
2022 Returns the number of objects in sequence \var{o} on success, and
2023 \code{-1} on failure. For objects that do not provide sequence
2024 protocol, this is equivalent to the Python expression
2025 \samp{len(\var{o})}.\bifuncindex{len}
2028 \begin{cfuncdesc}{int}{PySequence_Length}{PyObject *o}
2029 Alternate name for \cfunction{PySequence_Size()}.
2032 \begin{cfuncdesc}{PyObject*}{PySequence_Concat}{PyObject *o1, PyObject *o2}
2033 Return the concatenation of \var{o1} and \var{o2} on success, and \NULL{} on
2034 failure. This is the equivalent of the Python
2035 expression \samp{\var{o1} + \var{o2}}.
2039 \begin{cfuncdesc}{PyObject*}{PySequence_Repeat}{PyObject *o, int count}
2040 Return the result of repeating sequence object
2041 \var{o} \var{count} times, or \NULL{} on failure. This is the
2042 equivalent of the Python expression \samp{\var{o} * \var{count}}.
2045 \begin{cfuncdesc}{PyObject*}{PySequence_InPlaceConcat}{PyObject *o1,
2047 Return the concatenation of \var{o1} and \var{o2} on success, and \NULL{} on
2048 failure. The operation is done \emph{in-place} when \var{o1} supports it.
2049 This is the equivalent of the Python expression \samp{\var{o1} += \var{o2}}.
2053 \begin{cfuncdesc}{PyObject*}{PySequence_InPlaceRepeat}{PyObject *o, int count}
2054 Return the result of repeating sequence object \var{o} \var{count} times, or
2055 \NULL{} on failure. The operation is done \emph{in-place} when \var{o}
2056 supports it. This is the equivalent of the Python expression \samp{\var{o}
2061 \begin{cfuncdesc}{PyObject*}{PySequence_GetItem}{PyObject *o, int i}
2062 Return the \var{i}th element of \var{o}, or \NULL{} on failure. This
2063 is the equivalent of the Python expression \samp{\var{o}[\var{i}]}.
2067 \begin{cfuncdesc}{PyObject*}{PySequence_GetSlice}{PyObject *o, int i1, int i2}
2068 Return the slice of sequence object \var{o} between \var{i1} and
2069 \var{i2}, or \NULL{} on failure. This is the equivalent of the Python
2070 expression \samp{\var{o}[\var{i1}:\var{i2}]}.
2074 \begin{cfuncdesc}{int}{PySequence_SetItem}{PyObject *o, int i, PyObject *v}
2075 Assign object \var{v} to the \var{i}th element of \var{o}.
2076 Returns \code{-1} on failure. This is the equivalent of the Python
2077 statement \samp{\var{o}[\var{i}] = \var{v}}.
2080 \begin{cfuncdesc}{int}{PySequence_DelItem}{PyObject *o, int i}
2081 Delete the \var{i}th element of object \var{o}. Returns
2082 \code{-1} on failure. This is the equivalent of the Python
2083 statement \samp{del \var{o}[\var{i}]}.
2086 \begin{cfuncdesc}{int}{PySequence_SetSlice}{PyObject *o, int i1,
2087 int i2, PyObject *v}
2088 Assign the sequence object \var{v} to the slice in sequence
2089 object \var{o} from \var{i1} to \var{i2}. This is the equivalent of
2090 the Python statement \samp{\var{o}[\var{i1}:\var{i2}] = \var{v}}.
2093 \begin{cfuncdesc}{int}{PySequence_DelSlice}{PyObject *o, int i1, int i2}
2094 Delete the slice in sequence object \var{o} from \var{i1} to \var{i2}.
2095 Returns \code{-1} on failure. This is the equivalent of the Python
2096 statement \samp{del \var{o}[\var{i1}:\var{i2}]}.
2099 \begin{cfuncdesc}{PyObject*}{PySequence_Tuple}{PyObject *o}
2100 Returns the \var{o} as a tuple on success, and \NULL{} on failure.
2101 This is equivalent to the Python expression \samp{tuple(\var{o})}.
2105 \begin{cfuncdesc}{int}{PySequence_Count}{PyObject *o, PyObject *value}
2106 Return the number of occurrences of \var{value} in \var{o}, that is,
2107 return the number of keys for which \code{\var{o}[\var{key}] ==
2108 \var{value}}. On failure, return \code{-1}. This is equivalent to
2109 the Python expression \samp{\var{o}.count(\var{value})}.
2112 \begin{cfuncdesc}{int}{PySequence_Contains}{PyObject *o, PyObject *value}
2113 Determine if \var{o} contains \var{value}. If an item in \var{o} is
2114 equal to \var{value}, return \code{1}, otherwise return \code{0}. On
2115 error, return \code{-1}. This is equivalent to the Python expression
2116 \samp{\var{value} in \var{o}}.
2119 \begin{cfuncdesc}{int}{PySequence_Index}{PyObject *o, PyObject *value}
2120 Return the first index \var{i} for which \code{\var{o}[\var{i}] ==
2121 \var{value}}. On error, return \code{-1}. This is equivalent to
2122 the Python expression \samp{\var{o}.index(\var{value})}.
2125 \begin{cfuncdesc}{PyObject*}{PySequence_List}{PyObject *o}
2126 Return a list object with the same contents as the arbitrary sequence
2127 \var{o}. The returned list is guaranteed to be new.
2130 \begin{cfuncdesc}{PyObject*}{PySequence_Tuple}{PyObject *o}
2131 Return a tuple object with the same contents as the arbitrary sequence
2132 \var{o}. If \var{o} is a tuple, a new reference will be returned,
2133 otherwise a tuple will be constructed with the appropriate contents.
2137 \begin{cfuncdesc}{PyObject*}{PySequence_Fast}{PyObject *o, const char *m}
2138 Returns the sequence \var{o} as a tuple, unless it is already a
2139 tuple or list, in which case \var{o} is returned. Use
2140 \cfunction{PySequence_Fast_GET_ITEM()} to access the members of the
2141 result. Returns \NULL{} on failure. If the object is not a sequence,
2142 raises \exception{TypeError} with \var{m} as the message text.
2145 \begin{cfuncdesc}{PyObject*}{PySequence_Fast_GET_ITEM}{PyObject *o, int i}
2146 Return the \var{i}th element of \var{o}, assuming that \var{o} was
2147 returned by \cfunction{PySequence_Fast()}, and that \var{i} is within
2148 bounds. The caller is expected to get the length of the sequence by
2149 calling \cfunction{PySequence_Size()} on \var{o}, since lists and tuples
2150 are guaranteed to always return their true length.
2154 \section{Mapping Protocol \label{mapping}}
2156 \begin{cfuncdesc}{int}{PyMapping_Check}{PyObject *o}
2157 Return \code{1} if the object provides mapping protocol, and
2158 \code{0} otherwise. This function always succeeds.
2162 \begin{cfuncdesc}{int}{PyMapping_Length}{PyObject *o}
2163 Returns the number of keys in object \var{o} on success, and
2164 \code{-1} on failure. For objects that do not provide mapping
2165 protocol, this is equivalent to the Python expression
2166 \samp{len(\var{o})}.\bifuncindex{len}
2170 \begin{cfuncdesc}{int}{PyMapping_DelItemString}{PyObject *o, char *key}
2171 Remove the mapping for object \var{key} from the object \var{o}.
2172 Return \code{-1} on failure. This is equivalent to
2173 the Python statement \samp{del \var{o}[\var{key}]}.
2177 \begin{cfuncdesc}{int}{PyMapping_DelItem}{PyObject *o, PyObject *key}
2178 Remove the mapping for object \var{key} from the object \var{o}.
2179 Return \code{-1} on failure. This is equivalent to
2180 the Python statement \samp{del \var{o}[\var{key}]}.
2184 \begin{cfuncdesc}{int}{PyMapping_HasKeyString}{PyObject *o, char *key}
2185 On success, return \code{1} if the mapping object has the key
2186 \var{key} and \code{0} otherwise. This is equivalent to the Python
2187 expression \samp{\var{o}.has_key(\var{key})}.
2188 This function always succeeds.
2192 \begin{cfuncdesc}{int}{PyMapping_HasKey}{PyObject *o, PyObject *key}
2193 Return \code{1} if the mapping object has the key \var{key} and
2194 \code{0} otherwise. This is equivalent to the Python expression
2195 \samp{\var{o}.has_key(\var{key})}.
2196 This function always succeeds.
2200 \begin{cfuncdesc}{PyObject*}{PyMapping_Keys}{PyObject *o}
2201 On success, return a list of the keys in object \var{o}. On
2202 failure, return \NULL{}. This is equivalent to the Python
2203 expression \samp{\var{o}.keys()}.
2207 \begin{cfuncdesc}{PyObject*}{PyMapping_Values}{PyObject *o}
2208 On success, return a list of the values in object \var{o}. On
2209 failure, return \NULL{}. This is equivalent to the Python
2210 expression \samp{\var{o}.values()}.
2214 \begin{cfuncdesc}{PyObject*}{PyMapping_Items}{PyObject *o}
2215 On success, return a list of the items in object \var{o}, where
2216 each item is a tuple containing a key-value pair. On
2217 failure, return \NULL{}. This is equivalent to the Python
2218 expression \samp{\var{o}.items()}.
2222 \begin{cfuncdesc}{PyObject*}{PyMapping_GetItemString}{PyObject *o, char *key}
2223 Return element of \var{o} corresponding to the object \var{key} or
2224 \NULL{} on failure. This is the equivalent of the Python expression
2225 \samp{\var{o}[\var{key}]}.
2228 \begin{cfuncdesc}{int}{PyMapping_SetItemString}{PyObject *o, char *key,
2230 Map the object \var{key} to the value \var{v} in object \var{o}.
2231 Returns \code{-1} on failure. This is the equivalent of the Python
2232 statement \samp{\var{o}[\var{key}] = \var{v}}.
2236 \section{Iterator Protocol \label{iterator}}
2240 There are only a couple of functions specifically for working with
2243 \begin{cfuncdesc}{int}{PyIter_Check}{PyObject *o}
2244 Return true if the object \var{o} supports the iterator protocol.
2247 \begin{cfuncdesc}{PyObject*}{PyIter_Next}{PyObject *o}
2248 Return the next value from the iteration \var{o}. If the object is
2249 an iterator, this retrieves the next value from the iteration, and
2250 returns \NULL{} with no exception set if there are no remaining
2251 items. If the object is not an iterator, \exception{TypeError} is
2252 raised, or if there is an error in retrieving the item, returns
2253 \NULL{} and passes along the exception.
2256 To write a loop which iterates over an iterator, the C code should
2257 look something like this:
2260 PyObject *iterator = ...;
2263 while (item = PyIter_Next(iter)) {
2264 /* do something with item */
2266 if (PyErr_Occurred()) {
2267 /* propogate error */
2270 /* continue doing useful work */
2275 \chapter{Concrete Objects Layer \label{concrete}}
2277 The functions in this chapter are specific to certain Python object
2278 types. Passing them an object of the wrong type is not a good idea;
2279 if you receive an object from a Python program and you are not sure
2280 that it has the right type, you must perform a type check first;
2281 for example, to check that an object is a dictionary, use
2282 \cfunction{PyDict_Check()}. The chapter is structured like the
2283 ``family tree'' of Python object types.
2286 While the functions described in this chapter carefully check the type
2287 of the objects which are passed in, many of them do not check for
2288 \NULL{} being passed instead of a valid object. Allowing \NULL{} to
2289 be passed in can cause memory access violations and immediate
2290 termination of the interpreter.
2293 \section{Fundamental Objects \label{fundamental}}
2295 This section describes Python type objects and the singleton object
2299 \subsection{Type Objects \label{typeObjects}}
2302 \begin{ctypedesc}{PyTypeObject}
2303 The C structure of the objects used to describe built-in types.
2306 \begin{cvardesc}{PyObject*}{PyType_Type}
2307 This is the type object for type objects; it is the same object as
2308 \code{types.TypeType} in the Python layer.
2309 \withsubitem{(in module types)}{\ttindex{TypeType}}
2312 \begin{cfuncdesc}{int}{PyType_Check}{PyObject *o}
2313 Returns true is the object \var{o} is a type object.
2316 \begin{cfuncdesc}{int}{PyType_HasFeature}{PyObject *o, int feature}
2317 Returns true if the type object \var{o} sets the feature
2318 \var{feature}. Type features are denoted by single bit flags.
2322 \subsection{The None Object \label{noneObject}}
2324 \obindex{None@\texttt{None}}
2325 Note that the \ctype{PyTypeObject} for \code{None} is not directly
2326 exposed in the Python/C API. Since \code{None} is a singleton,
2327 testing for object identity (using \samp{==} in C) is sufficient.
2328 There is no \cfunction{PyNone_Check()} function for the same reason.
2330 \begin{cvardesc}{PyObject*}{Py_None}
2331 The Python \code{None} object, denoting lack of value. This object has
2336 \section{Numeric Objects \label{numericObjects}}
2341 \subsection{Plain Integer Objects \label{intObjects}}
2344 \begin{ctypedesc}{PyIntObject}
2345 This subtype of \ctype{PyObject} represents a Python integer object.
2348 \begin{cvardesc}{PyTypeObject}{PyInt_Type}
2349 This instance of \ctype{PyTypeObject} represents the Python plain
2350 integer type. This is the same object as \code{types.IntType}.
2351 \withsubitem{(in modules types)}{\ttindex{IntType}}
2354 \begin{cfuncdesc}{int}{PyInt_Check}{PyObject* o}
2355 Returns true if \var{o} is of type \cdata{PyInt_Type}.
2358 \begin{cfuncdesc}{PyObject*}{PyInt_FromLong}{long ival}
2359 Creates a new integer object with a value of \var{ival}.
2361 The current implementation keeps an array of integer objects for all
2362 integers between \code{-1} and \code{100}, when you create an int in
2363 that range you actually just get back a reference to the existing
2364 object. So it should be possible to change the value of \code{1}. I
2365 suspect the behaviour of Python in this case is undefined. :-)
2368 \begin{cfuncdesc}{long}{PyInt_AsLong}{PyObject *io}
2369 Will first attempt to cast the object to a \ctype{PyIntObject}, if
2370 it is not already one, and then return its value.
2373 \begin{cfuncdesc}{long}{PyInt_AS_LONG}{PyObject *io}
2374 Returns the value of the object \var{io}. No error checking is
2378 \begin{cfuncdesc}{long}{PyInt_GetMax}{}
2379 Returns the system's idea of the largest integer it can handle
2380 (\constant{LONG_MAX}\ttindex{LONG_MAX}, as defined in the system
2385 \subsection{Long Integer Objects \label{longObjects}}
2387 \obindex{long integer}
2388 \begin{ctypedesc}{PyLongObject}
2389 This subtype of \ctype{PyObject} represents a Python long integer
2393 \begin{cvardesc}{PyTypeObject}{PyLong_Type}
2394 This instance of \ctype{PyTypeObject} represents the Python long
2395 integer type. This is the same object as \code{types.LongType}.
2396 \withsubitem{(in modules types)}{\ttindex{LongType}}
2399 \begin{cfuncdesc}{int}{PyLong_Check}{PyObject *p}
2400 Returns true if its argument is a \ctype{PyLongObject}.
2403 \begin{cfuncdesc}{PyObject*}{PyLong_FromLong}{long v}
2404 Returns a new \ctype{PyLongObject} object from \var{v}, or \NULL{} on
2408 \begin{cfuncdesc}{PyObject*}{PyLong_FromUnsignedLong}{unsigned long v}
2409 Returns a new \ctype{PyLongObject} object from a C \ctype{unsigned
2410 long}, or \NULL{} on failure.
2413 \begin{cfuncdesc}{PyObject*}{PyLong_FromDouble}{double v}
2414 Returns a new \ctype{PyLongObject} object from the integer part of
2415 \var{v}, or \NULL{} on failure.
2418 \begin{cfuncdesc}{long}{PyLong_AsLong}{PyObject *pylong}
2419 Returns a C \ctype{long} representation of the contents of
2420 \var{pylong}. If \var{pylong} is greater than
2421 \constant{LONG_MAX}\ttindex{LONG_MAX}, an \exception{OverflowError} is
2422 raised.\withsubitem{(built-in exception)}{\ttindex{OverflowError}}
2425 \begin{cfuncdesc}{unsigned long}{PyLong_AsUnsignedLong}{PyObject *pylong}
2426 Returns a C \ctype{unsigned long} representation of the contents of
2427 \var{pylong}. If \var{pylong} is greater than
2428 \constant{ULONG_MAX}\ttindex{ULONG_MAX}, an \exception{OverflowError}
2429 is raised.\withsubitem{(built-in exception)}{\ttindex{OverflowError}}
2432 \begin{cfuncdesc}{double}{PyLong_AsDouble}{PyObject *pylong}
2433 Returns a C \ctype{double} representation of the contents of \var{pylong}.
2436 \begin{cfuncdesc}{PyObject*}{PyLong_FromString}{char *str, char **pend,
2438 Return a new \ctype{PyLongObject} based on the string value in
2439 \var{str}, which is interpreted according to the radix in \var{base}.
2440 If \var{pend} is non-\NULL, \code{*\var{pend}} will point to the first
2441 character in \var{str} which follows the representation of the
2442 number. If \var{base} is \code{0}, the radix will be determined base
2443 on the leading characters of \var{str}: if \var{str} starts with
2444 \code{'0x'} or \code{'0X'}, radix 16 will be used; if \var{str} starts
2445 with \code{'0'}, radix 8 will be used; otherwise radix 10 will be
2446 used. If \var{base} is not \code{0}, it must be between \code{2} and
2447 \code{36}, inclusive. Leading spaces are ignored. If there are no
2448 digits, \exception{ValueError} will be raised.
2452 \subsection{Floating Point Objects \label{floatObjects}}
2454 \obindex{floating point}
2455 \begin{ctypedesc}{PyFloatObject}
2456 This subtype of \ctype{PyObject} represents a Python floating point
2460 \begin{cvardesc}{PyTypeObject}{PyFloat_Type}
2461 This instance of \ctype{PyTypeObject} represents the Python floating
2462 point type. This is the same object as \code{types.FloatType}.
2463 \withsubitem{(in modules types)}{\ttindex{FloatType}}
2466 \begin{cfuncdesc}{int}{PyFloat_Check}{PyObject *p}
2467 Returns true if its argument is a \ctype{PyFloatObject}.
2470 \begin{cfuncdesc}{PyObject*}{PyFloat_FromDouble}{double v}
2471 Creates a \ctype{PyFloatObject} object from \var{v}, or \NULL{} on
2475 \begin{cfuncdesc}{double}{PyFloat_AsDouble}{PyObject *pyfloat}
2476 Returns a C \ctype{double} representation of the contents of \var{pyfloat}.
2479 \begin{cfuncdesc}{double}{PyFloat_AS_DOUBLE}{PyObject *pyfloat}
2480 Returns a C \ctype{double} representation of the contents of
2481 \var{pyfloat}, but without error checking.
2485 \subsection{Complex Number Objects \label{complexObjects}}
2487 \obindex{complex number}
2488 Python's complex number objects are implemented as two distinct types
2489 when viewed from the C API: one is the Python object exposed to
2490 Python programs, and the other is a C structure which represents the
2491 actual complex number value. The API provides functions for working
2494 \subsubsection{Complex Numbers as C Structures}
2496 Note that the functions which accept these structures as parameters
2497 and return them as results do so \emph{by value} rather than
2498 dereferencing them through pointers. This is consistent throughout
2501 \begin{ctypedesc}{Py_complex}
2502 The C structure which corresponds to the value portion of a Python
2503 complex number object. Most of the functions for dealing with complex
2504 number objects use structures of this type as input or output values,
2505 as appropriate. It is defined as:
2515 \begin{cfuncdesc}{Py_complex}{_Py_c_sum}{Py_complex left, Py_complex right}
2516 Return the sum of two complex numbers, using the C
2517 \ctype{Py_complex} representation.
2520 \begin{cfuncdesc}{Py_complex}{_Py_c_diff}{Py_complex left, Py_complex right}
2521 Return the difference between two complex numbers, using the C
2522 \ctype{Py_complex} representation.
2525 \begin{cfuncdesc}{Py_complex}{_Py_c_neg}{Py_complex complex}
2526 Return the negation of the complex number \var{complex}, using the C
2527 \ctype{Py_complex} representation.
2530 \begin{cfuncdesc}{Py_complex}{_Py_c_prod}{Py_complex left, Py_complex right}
2531 Return the product of two complex numbers, using the C
2532 \ctype{Py_complex} representation.
2535 \begin{cfuncdesc}{Py_complex}{_Py_c_quot}{Py_complex dividend,
2537 Return the quotient of two complex numbers, using the C
2538 \ctype{Py_complex} representation.
2541 \begin{cfuncdesc}{Py_complex}{_Py_c_pow}{Py_complex num, Py_complex exp}
2542 Return the exponentiation of \var{num} by \var{exp}, using the C
2543 \ctype{Py_complex} representation.
2547 \subsubsection{Complex Numbers as Python Objects}
2549 \begin{ctypedesc}{PyComplexObject}
2550 This subtype of \ctype{PyObject} represents a Python complex number object.
2553 \begin{cvardesc}{PyTypeObject}{PyComplex_Type}
2554 This instance of \ctype{PyTypeObject} represents the Python complex
2558 \begin{cfuncdesc}{int}{PyComplex_Check}{PyObject *p}
2559 Returns true if its argument is a \ctype{PyComplexObject}.
2562 \begin{cfuncdesc}{PyObject*}{PyComplex_FromCComplex}{Py_complex v}
2563 Create a new Python complex number object from a C
2564 \ctype{Py_complex} value.
2567 \begin{cfuncdesc}{PyObject*}{PyComplex_FromDoubles}{double real, double imag}
2568 Returns a new \ctype{PyComplexObject} object from \var{real} and \var{imag}.
2571 \begin{cfuncdesc}{double}{PyComplex_RealAsDouble}{PyObject *op}
2572 Returns the real part of \var{op} as a C \ctype{double}.
2575 \begin{cfuncdesc}{double}{PyComplex_ImagAsDouble}{PyObject *op}
2576 Returns the imaginary part of \var{op} as a C \ctype{double}.
2579 \begin{cfuncdesc}{Py_complex}{PyComplex_AsCComplex}{PyObject *op}
2580 Returns the \ctype{Py_complex} value of the complex number \var{op}.
2585 \section{Sequence Objects \label{sequenceObjects}}
2588 Generic operations on sequence objects were discussed in the previous
2589 chapter; this section deals with the specific kinds of sequence
2590 objects that are intrinsic to the Python language.
2593 \subsection{String Objects \label{stringObjects}}
2595 These functions raise \exception{TypeError} when expecting a string
2596 parameter and are called with a non-string parameter.
2599 \begin{ctypedesc}{PyStringObject}
2600 This subtype of \ctype{PyObject} represents a Python string object.
2603 \begin{cvardesc}{PyTypeObject}{PyString_Type}
2604 This instance of \ctype{PyTypeObject} represents the Python string
2605 type; it is the same object as \code{types.TypeType} in the Python
2606 layer.\withsubitem{(in module types)}{\ttindex{StringType}}.
2609 \begin{cfuncdesc}{int}{PyString_Check}{PyObject *o}
2610 Returns true if the object \var{o} is a string object.
2613 \begin{cfuncdesc}{PyObject*}{PyString_FromString}{const char *v}
2614 Returns a new string object with the value \var{v} on success, and
2618 \begin{cfuncdesc}{PyObject*}{PyString_FromStringAndSize}{const char *v,
2620 Returns a new string object with the value \var{v} and length
2621 \var{len} on success, and \NULL{} on failure. If \var{v} is \NULL{},
2622 the contents of the string are uninitialized.
2625 \begin{cfuncdesc}{int}{PyString_Size}{PyObject *string}
2626 Returns the length of the string in string object \var{string}.
2629 \begin{cfuncdesc}{int}{PyString_GET_SIZE}{PyObject *string}
2630 Macro form of \cfunction{PyString_Size()} but without error
2634 \begin{cfuncdesc}{char*}{PyString_AsString}{PyObject *string}
2635 Returns a null-terminated representation of the contents of
2636 \var{string}. The pointer refers to the internal buffer of
2637 \var{string}, not a copy. The data must not be modified in any way,
2638 unless the string was just created using
2639 \code{PyString_FromStringAndSize(NULL, \var{size})}.
2640 It must not be deallocated.
2643 \begin{cfuncdesc}{char*}{PyString_AS_STRING}{PyObject *string}
2644 Macro form of \cfunction{PyString_AsString()} but without error
2648 \begin{cfuncdesc}{int}{PyString_AsStringAndSize}{PyObject *obj,
2651 Returns a null-terminated representation of the contents of the object
2652 \var{obj} through the output variables \var{buffer} and \var{length}.
2654 The function accepts both string and Unicode objects as input. For
2655 Unicode objects it returns the default encoded version of the object.
2656 If \var{length} is set to \NULL{}, the resulting buffer may not contain
2657 null characters; if it does, the function returns -1 and a
2658 TypeError is raised.
2660 The buffer refers to an internal string buffer of \var{obj}, not a
2661 copy. The data must not be modified in any way, unless the string was
2662 just created using \code{PyString_FromStringAndSize(NULL,
2663 \var{size})}. It must not be deallocated.
2666 \begin{cfuncdesc}{void}{PyString_Concat}{PyObject **string,
2668 Creates a new string object in \var{*string} containing the
2669 contents of \var{newpart} appended to \var{string}; the caller will
2670 own the new reference. The reference to the old value of \var{string}
2671 will be stolen. If the new string
2672 cannot be created, the old reference to \var{string} will still be
2673 discarded and the value of \var{*string} will be set to
2674 \NULL{}; the appropriate exception will be set.
2677 \begin{cfuncdesc}{void}{PyString_ConcatAndDel}{PyObject **string,
2679 Creates a new string object in \var{*string} containing the contents
2680 of \var{newpart} appended to \var{string}. This version decrements
2681 the reference count of \var{newpart}.
2684 \begin{cfuncdesc}{int}{_PyString_Resize}{PyObject **string, int newsize}
2685 A way to resize a string object even though it is ``immutable''.
2686 Only use this to build up a brand new string object; don't use this if
2687 the string may already be known in other parts of the code.
2690 \begin{cfuncdesc}{PyObject*}{PyString_Format}{PyObject *format,
2692 Returns a new string object from \var{format} and \var{args}. Analogous
2693 to \code{\var{format} \%\ \var{args}}. The \var{args} argument must be
2697 \begin{cfuncdesc}{void}{PyString_InternInPlace}{PyObject **string}
2698 Intern the argument \var{*string} in place. The argument must be the
2699 address of a pointer variable pointing to a Python string object.
2700 If there is an existing interned string that is the same as
2701 \var{*string}, it sets \var{*string} to it (decrementing the reference
2702 count of the old string object and incrementing the reference count of
2703 the interned string object), otherwise it leaves \var{*string} alone
2704 and interns it (incrementing its reference count). (Clarification:
2705 even though there is a lot of talk about reference counts, think of
2706 this function as reference-count-neutral; you own the object after
2707 the call if and only if you owned it before the call.)
2710 \begin{cfuncdesc}{PyObject*}{PyString_InternFromString}{const char *v}
2711 A combination of \cfunction{PyString_FromString()} and
2712 \cfunction{PyString_InternInPlace()}, returning either a new string object
2713 that has been interned, or a new (``owned'') reference to an earlier
2714 interned string object with the same value.
2717 \begin{cfuncdesc}{PyObject*}{PyString_Decode}{const char *s,
2719 const char *encoding,
2721 Creates an object by decoding \var{size} bytes of the encoded
2722 buffer \var{s} using the codec registered
2723 for \var{encoding}. \var{encoding} and \var{errors} have the same meaning
2724 as the parameters of the same name in the unicode() builtin
2725 function. The codec to be used is looked up using the Python codec
2726 registry. Returns \NULL{} in case an exception was raised by the
2730 \begin{cfuncdesc}{PyObject*}{PyString_AsDecodedObject}{PyObject *str,
2731 const char *encoding,
2733 Decodes a string object by passing it to the codec registered
2734 for \var{encoding} and returns the result as Python
2735 object. \var{encoding} and \var{errors} have the same meaning as the
2736 parameters of the same name in the string .encode() method. The codec
2737 to be used is looked up using the Python codec registry. Returns
2738 \NULL{} in case an exception was raised by the codec.
2741 \begin{cfuncdesc}{PyObject*}{PyString_Encode}{const char *s,
2743 const char *encoding,
2745 Encodes the \ctype{char} buffer of the given size by passing it to
2746 the codec registered for \var{encoding} and returns a Python object.
2747 \var{encoding} and \var{errors} have the same
2748 meaning as the parameters of the same name in the string .encode()
2749 method. The codec to be used is looked up using the Python codec
2750 registry. Returns \NULL{} in case an exception was raised by the
2754 \begin{cfuncdesc}{PyObject*}{PyString_AsEncodedObject}{PyObject *str,
2755 const char *encoding,
2757 Encodes a string object using the codec registered
2758 for \var{encoding} and returns the result as Python
2759 object. \var{encoding} and \var{errors} have the same meaning as the
2760 parameters of the same name in the string .encode() method. The codec
2761 to be used is looked up using the Python codec registry. Returns
2762 \NULL{} in case an exception was raised by the codec.
2766 \subsection{Unicode Objects \label{unicodeObjects}}
2767 \sectionauthor{Marc-Andre Lemburg}{mal@lemburg.com}
2769 %--- Unicode Type -------------------------------------------------------
2771 These are the basic Unicode object types used for the Unicode
2772 implementation in Python:
2774 \begin{ctypedesc}{Py_UNICODE}
2775 This type represents a 16-bit unsigned storage type which is used by
2776 Python internally as basis for holding Unicode ordinals. On platforms
2777 where \ctype{wchar_t} is available and also has 16-bits,
2778 \ctype{Py_UNICODE} is a typedef alias for \ctype{wchar_t} to enhance
2779 native platform compatibility. On all other platforms,
2780 \ctype{Py_UNICODE} is a typedef alias for \ctype{unsigned short}.
2783 \begin{ctypedesc}{PyUnicodeObject}
2784 This subtype of \ctype{PyObject} represents a Python Unicode object.
2787 \begin{cvardesc}{PyTypeObject}{PyUnicode_Type}
2788 This instance of \ctype{PyTypeObject} represents the Python Unicode type.
2791 %--- These are really C macros... is there a macrodesc TeX macro ?
2793 The following APIs are really C macros and can be used to do fast
2794 checks and to access internal read-only data of Unicode objects:
2796 \begin{cfuncdesc}{int}{PyUnicode_Check}{PyObject *o}
2797 Returns true if the object \var{o} is a Unicode object.
2800 \begin{cfuncdesc}{int}{PyUnicode_GET_SIZE}{PyObject *o}
2801 Returns the size of the object. o has to be a
2802 PyUnicodeObject (not checked).
2805 \begin{cfuncdesc}{int}{PyUnicode_GET_DATA_SIZE}{PyObject *o}
2806 Returns the size of the object's internal buffer in bytes. o has to be
2807 a PyUnicodeObject (not checked).
2810 \begin{cfuncdesc}{Py_UNICODE*}{PyUnicode_AS_UNICODE}{PyObject *o}
2811 Returns a pointer to the internal Py_UNICODE buffer of the object. o
2812 has to be a PyUnicodeObject (not checked).
2815 \begin{cfuncdesc}{const char*}{PyUnicode_AS_DATA}{PyObject *o}
2816 Returns a (const char *) pointer to the internal buffer of the object.
2817 o has to be a PyUnicodeObject (not checked).
2820 % --- Unicode character properties ---------------------------------------
2822 Unicode provides many different character properties. The most often
2823 needed ones are available through these macros which are mapped to C
2824 functions depending on the Python configuration.
2826 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISSPACE
}{Py_UNICODE ch
}
2827 Returns
1/
0 depending on whether
\var{ch
} is a whitespace character.
2830 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISLOWER
}{Py_UNICODE ch
}
2831 Returns
1/
0 depending on whether
\var{ch
} is a lowercase character.
2834 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISUPPER
}{Py_UNICODE ch
}
2835 Returns
1/
0 depending on whether
\var{ch
} is an uppercase character.
2838 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISTITLE
}{Py_UNICODE ch
}
2839 Returns
1/
0 depending on whether
\var{ch
} is a titlecase character.
2842 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISLINEBREAK
}{Py_UNICODE ch
}
2843 Returns
1/
0 depending on whether
\var{ch
} is a linebreak character.
2846 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISDECIMAL
}{Py_UNICODE ch
}
2847 Returns
1/
0 depending on whether
\var{ch
} is a decimal character.
2850 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISDIGIT
}{Py_UNICODE ch
}
2851 Returns
1/
0 depending on whether
\var{ch
} is a digit character.
2854 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISNUMERIC
}{Py_UNICODE ch
}
2855 Returns
1/
0 depending on whether
\var{ch
} is a numeric character.
2858 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISALPHA
}{Py_UNICODE ch
}
2859 Returns
1/
0 depending on whether
\var{ch
} is an alphabetic character.
2862 \begin{cfuncdesc
}{int
}{Py_UNICODE_ISALNUM
}{Py_UNICODE ch
}
2863 Returns
1/
0 depending on whether
\var{ch
} is an alphanumeric character.
2866 These APIs can be used for fast direct character conversions:
2868 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOLOWER
}{Py_UNICODE ch
}
2869 Returns the character
\var{ch
} converted to lower case.
2872 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOUPPER
}{Py_UNICODE ch
}
2873 Returns the character
\var{ch
} converted to upper case.
2876 \begin{cfuncdesc
}{Py_UNICODE
}{Py_UNICODE_TOTITLE
}{Py_UNICODE ch
}
2877 Returns the character
\var{ch
} converted to title case.
2880 \begin{cfuncdesc
}{int
}{Py_UNICODE_TODECIMAL
}{Py_UNICODE ch
}
2881 Returns the character
\var{ch
} converted to a decimal positive integer.
2882 Returns -
1 in case this is not possible. Does not raise exceptions.
2885 \begin{cfuncdesc
}{int
}{Py_UNICODE_TODIGIT
}{Py_UNICODE ch
}
2886 Returns the character
\var{ch
} converted to a single digit integer.
2887 Returns -
1 in case this is not possible. Does not raise exceptions.
2890 \begin{cfuncdesc
}{double
}{Py_UNICODE_TONUMERIC
}{Py_UNICODE ch
}
2891 Returns the character
\var{ch
} converted to a (positive) double.
2892 Returns -
1.0 in case this is not possible. Does not raise exceptions.
2895 % --- Plain Py_UNICODE ---------------------------------------------------
2897 To create Unicode objects and access their basic sequence properties,
2900 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromUnicode
}{const Py_UNICODE *u,
2903 Create a Unicode Object from the Py_UNICODE buffer
\var{u
} of the
2904 given size.
\var{u
} may be
\NULL{} which causes the contents to be
2905 undefined. It is the user's responsibility to fill in the needed data.
2906 The buffer is copied into the new object. If the buffer is not
\NULL{},
2907 the return value might be a shared object. Therefore, modification of
2908 the resulting Unicode Object is only allowed when
\var{u
} is
\NULL{}.
2911 \begin{cfuncdesc
}{Py_UNICODE*
}{PyUnicode_AsUnicode
}{PyObject *unicode
}
2912 Return a read-only pointer to the Unicode object's internal
2913 \ctype{Py_UNICODE
} buffer.
2916 \begin{cfuncdesc
}{int
}{PyUnicode_GetSize
}{PyObject *unicode
}
2917 Return the length of the Unicode object.
2920 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromEncodedObject
}{PyObject *obj,
2921 const char *encoding,
2924 Coerce an encoded object obj to an Unicode object and return a
2925 reference with incremented refcount.
2927 Coercion is done in the following way:
2929 \item Unicode objects are passed back as-is with incremented
2930 refcount. Note: these cannot be decoded; passing a non-NULL
2931 value for encoding will result in a TypeError.
2933 \item String and other char buffer compatible objects are decoded
2934 according to the given encoding and using the error handling
2935 defined by errors. Both can be NULL to have the interface use
2936 the default values (see the next section for details).
2938 \item All other objects cause an exception.
2940 The API returns NULL in case of an error. The caller is responsible
2941 for decref'ing the returned objects.
2944 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromObject
}{PyObject *obj
}
2946 Shortcut for PyUnicode_FromEncodedObject(obj, NULL, ``strict'')
2947 which is used throughout the interpreter whenever coercion to
2951 % --- wchar_t support for platforms which support it ---------------------
2953 If the platform supports
\ctype{wchar_t
} and provides a header file
2954 wchar.h, Python can interface directly to this type using the
2955 following functions. Support is optimized if Python's own
2956 \ctype{Py_UNICODE
} type is identical to the system's
\ctype{wchar_t
}.
2958 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_FromWideChar
}{const wchar_t *w,
2960 Create a Unicode Object from the
\ctype{whcar_t
} buffer
\var{w
} of the
2961 given size. Returns
\NULL{} on failure.
2964 \begin{cfuncdesc
}{int
}{PyUnicode_AsWideChar
}{PyUnicodeObject *unicode,
2967 Copies the Unicode Object contents into the
\ctype{whcar_t
} buffer
2968 \var{w
}. At most
\var{size
} \ctype{whcar_t
} characters are copied.
2969 Returns the number of
\ctype{whcar_t
} characters copied or -
1 in case
2974 \subsubsection{Builtin Codecs
\label{builtinCodecs
}}
2976 Python provides a set of builtin codecs which are written in C
2977 for speed. All of these codecs are directly usable via the
2978 following functions.
2980 Many of the following APIs take two arguments encoding and
2981 errors. These parameters encoding and errors have the same semantics
2982 as the ones of the builtin unicode() Unicode object constructor.
2984 Setting encoding to NULL causes the default encoding to be used which
2987 Error handling is set by errors which may also be set to NULL meaning
2988 to use the default handling defined for the codec. Default error
2989 handling for all builtin codecs is ``strict'' (ValueErrors are raised).
2991 The codecs all use a similar interface. Only deviation from the
2992 following generic ones are documented for simplicity.
2994 % --- Generic Codecs -----------------------------------------------------
2996 These are the generic codec APIs:
2998 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Decode
}{const char *s,
3000 const char *encoding,
3002 Create a Unicode object by decoding
\var{size
} bytes of the encoded
3003 string
\var{s
}.
\var{encoding
} and
\var{errors
} have the same meaning
3004 as the parameters of the same name in the unicode() builtin
3005 function. The codec to be used is looked up using the Python codec
3006 registry. Returns
\NULL{} in case an exception was raised by the
3010 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Encode
}{const Py_UNICODE *s,
3012 const char *encoding,
3014 Encodes the
\ctype{Py_UNICODE
} buffer of the given size and returns a
3015 Python string object.
\var{encoding
} and
\var{errors
} have the same
3016 meaning as the parameters of the same name in the Unicode .encode()
3017 method. The codec to be used is looked up using the Python codec
3018 registry. Returns
\NULL{} in case an exception was raised by the
3022 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsEncodedString
}{PyObject *unicode,
3023 const char *encoding,
3025 Encodes a Unicode object and returns the result as Python string
3026 object.
\var{encoding
} and
\var{errors
} have the same meaning as the
3027 parameters of the same name in the Unicode .encode() method. The codec
3028 to be used is looked up using the Python codec registry. Returns
3029 \NULL{} in case an exception was raised by the codec.
3032 % --- UTF-8 Codecs -------------------------------------------------------
3034 These are the UTF-
8 codec APIs:
3036 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUTF8
}{const char *s,
3039 Creates a Unicode object by decoding
\var{size
} bytes of the UTF-
8
3040 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3041 raised by the codec.
3044 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUTF8
}{const Py_UNICODE *s,
3047 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using UTF-
8
3048 and returns a Python string object. Returns
\NULL{} in case an
3049 exception was raised by the codec.
3052 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUTF8String
}{PyObject *unicode
}
3053 Encodes a Unicode objects using UTF-
8 and returns the result as Python
3054 string object. Error handling is ``strict''. Returns
3055 \NULL{} in case an exception was raised by the codec.
3058 % --- UTF-16 Codecs ------------------------------------------------------ */
3060 These are the UTF-
16 codec APIs:
3062 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUTF16
}{const char *s,
3066 Decodes
\var{length
} bytes from a UTF-
16 encoded buffer string and
3067 returns the corresponding Unicode object.
3069 \var{errors
} (if non-NULL) defines the error handling. It defaults
3072 If
\var{byteorder
} is non-
\NULL{}, the decoder starts decoding using
3073 the given byte order:
3076 *byteorder == -
1: little endian
3077 *byteorder ==
0: native order
3078 *byteorder ==
1: big endian
3081 and then switches according to all byte order marks (BOM) it finds in
3082 the input data. BOM marks are not copied into the resulting Unicode
3083 string. After completion,
\var{*byteorder
} is set to the current byte
3084 order at the end of input data.
3086 If
\var{byteorder
} is
\NULL{}, the codec starts in native order mode.
3088 Returns
\NULL{} in case an exception was raised by the codec.
3091 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUTF16
}{const Py_UNICODE *s,
3095 Returns a Python string object holding the UTF-
16 encoded value of the
3096 Unicode data in
\var{s
}.
3098 If
\var{byteorder
} is not
\code{0}, output is written according to the
3099 following byte order:
3102 byteorder == -
1: little endian
3103 byteorder ==
0: native byte order (writes a BOM mark)
3104 byteorder ==
1: big endian
3107 If byteorder is
\code{0}, the output string will always start with the
3108 Unicode BOM mark (U+FEFF). In the other two modes, no BOM mark is
3111 Note that
\ctype{Py_UNICODE
} data is being interpreted as UTF-
16
3112 reduced to UCS-
2. This trick makes it possible to add full UTF-
16
3113 capabilities at a later point without comprimising the APIs.
3115 Returns
\NULL{} in case an exception was raised by the codec.
3118 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUTF16String
}{PyObject *unicode
}
3119 Returns a Python string using the UTF-
16 encoding in native byte
3120 order. The string always starts with a BOM mark. Error handling is
3121 ``strict''. Returns
\NULL{} in case an exception was raised by the
3125 % --- Unicode-Escape Codecs ----------------------------------------------
3127 These are the ``Unicode Esacpe'' codec APIs:
3129 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeUnicodeEscape
}{const char *s,
3132 Creates a Unicode object by decoding
\var{size
} bytes of the Unicode-Esacpe
3133 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3134 raised by the codec.
3137 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeUnicodeEscape
}{const Py_UNICODE *s,
3140 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Unicode-Escape
3141 and returns a Python string object. Returns
\NULL{} in case an
3142 exception was raised by the codec.
3145 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsUnicodeEscapeString
}{PyObject *unicode
}
3146 Encodes a Unicode objects using Unicode-Escape and returns the result
3147 as Python string object. Error handling is ``strict''. Returns
3148 \NULL{} in case an exception was raised by the codec.
3151 % --- Raw-Unicode-Escape Codecs ------------------------------------------
3153 These are the ``Raw Unicode Esacpe'' codec APIs:
3155 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeRawUnicodeEscape
}{const char *s,
3158 Creates a Unicode object by decoding
\var{size
} bytes of the Raw-Unicode-Esacpe
3159 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3160 raised by the codec.
3163 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeRawUnicodeEscape
}{const Py_UNICODE *s,
3166 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Raw-Unicode-Escape
3167 and returns a Python string object. Returns
\NULL{} in case an
3168 exception was raised by the codec.
3171 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsRawUnicodeEscapeString
}{PyObject *unicode
}
3172 Encodes a Unicode objects using Raw-Unicode-Escape and returns the result
3173 as Python string object. Error handling is ``strict''. Returns
3174 \NULL{} in case an exception was raised by the codec.
3177 % --- Latin-1 Codecs -----------------------------------------------------
3179 These are the Latin-
1 codec APIs:
3181 Latin-
1 corresponds to the first
256 Unicode ordinals and only these
3182 are accepted by the codecs during encoding.
3184 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeLatin1
}{const char *s,
3187 Creates a Unicode object by decoding
\var{size
} bytes of the Latin-
1
3188 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3189 raised by the codec.
3192 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeLatin1
}{const Py_UNICODE *s,
3195 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using Latin-
1
3196 and returns a Python string object. Returns
\NULL{} in case an
3197 exception was raised by the codec.
3200 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsLatin1String
}{PyObject *unicode
}
3201 Encodes a Unicode objects using Latin-
1 and returns the result as
3202 Python string object. Error handling is ``strict''. Returns
3203 \NULL{} in case an exception was raised by the codec.
3206 % --- ASCII Codecs -------------------------------------------------------
3208 These are the
\ASCII{} codec APIs. Only
7-bit
\ASCII{} data is
3209 accepted. All other codes generate errors.
3211 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeASCII
}{const char *s,
3214 Creates a Unicode object by decoding
\var{size
} bytes of the
3215 \ASCII{} encoded string
\var{s
}. Returns
\NULL{} in case an exception
3216 was raised by the codec.
3219 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeASCII
}{const Py_UNICODE *s,
3222 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using
3223 \ASCII{} and returns a Python string object. Returns
\NULL{} in case
3224 an exception was raised by the codec.
3227 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsASCIIString
}{PyObject *unicode
}
3228 Encodes a Unicode objects using
\ASCII{} and returns the result as Python
3229 string object. Error handling is ``strict''. Returns
3230 \NULL{} in case an exception was raised by the codec.
3233 % --- Character Map Codecs -----------------------------------------------
3235 These are the mapping codec APIs:
3237 This codec is special in that it can be used to implement many
3238 different codecs (and this is in fact what was done to obtain most of
3239 the standard codecs included in the
\module{encodings
} package). The
3240 codec uses mapping to encode and decode characters.
3242 Decoding mappings must map single string characters to single Unicode
3243 characters, integers (which are then interpreted as Unicode ordinals)
3244 or None (meaning "undefined mapping" and causing an error).
3246 Encoding mappings must map single Unicode characters to single string
3247 characters, integers (which are then interpreted as Latin-
1 ordinals)
3248 or None (meaning "undefined mapping" and causing an error).
3250 The mapping objects provided must only support the __getitem__ mapping
3253 If a character lookup fails with a LookupError, the character is
3254 copied as-is meaning that its ordinal value will be interpreted as
3255 Unicode or Latin-
1 ordinal resp. Because of this, mappings only need
3256 to contain those mappings which map characters to different code
3259 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeCharmap
}{const char *s,
3263 Creates a Unicode object by decoding
\var{size
} bytes of the encoded
3264 string
\var{s
} using the given
\var{mapping
} object. Returns
\NULL{}
3265 in case an exception was raised by the codec.
3268 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeCharmap
}{const Py_UNICODE *s,
3272 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using the
3273 given
\var{mapping
} object and returns a Python string object.
3274 Returns
\NULL{} in case an exception was raised by the codec.
3277 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsCharmapString
}{PyObject *unicode,
3279 Encodes a Unicode objects using the given
\var{mapping
} object and
3280 returns the result as Python string object. Error handling is
3281 ``strict''. Returns
\NULL{} in case an exception was raised by the
3285 The following codec API is special in that maps Unicode to Unicode.
3287 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_TranslateCharmap
}{const Py_UNICODE *s,
3291 Translates a
\ctype{Py_UNICODE
} buffer of the given length by applying
3292 a character mapping
\var{table
} to it and returns the resulting
3293 Unicode object. Returns
\NULL{} when an exception was raised by the
3296 The
\var{mapping
} table must map Unicode ordinal integers to Unicode
3297 ordinal integers or None (causing deletion of the character).
3299 Mapping tables must only provide the __getitem__ interface,
3300 e.g. dictionaries or sequences. Unmapped character ordinals (ones
3301 which cause a LookupError) are left untouched and are copied as-is.
3304 % --- MBCS codecs for Windows --------------------------------------------
3306 These are the MBCS codec APIs. They are currently only available on
3307 Windows and use the Win32 MBCS converters to implement the
3308 conversions. Note that MBCS (or DBCS) is a class of encodings, not
3309 just one. The target encoding is defined by the user settings on the
3310 machine running the codec.
3312 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_DecodeMBCS
}{const char *s,
3315 Creates a Unicode object by decoding
\var{size
} bytes of the MBCS
3316 encoded string
\var{s
}. Returns
\NULL{} in case an exception was
3317 raised by the codec.
3320 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_EncodeMBCS
}{const Py_UNICODE *s,
3323 Encodes the
\ctype{Py_UNICODE
} buffer of the given size using MBCS
3324 and returns a Python string object. Returns
\NULL{} in case an
3325 exception was raised by the codec.
3328 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_AsMBCSString
}{PyObject *unicode
}
3329 Encodes a Unicode objects using MBCS and returns the result as Python
3330 string object. Error handling is ``strict''. Returns
\NULL{} in case
3331 an exception was raised by the codec.
3334 % --- Methods & Slots ----------------------------------------------------
3336 \subsubsection{Methods and Slot Functions
\label{unicodeMethodsAndSlots
}}
3338 The following APIs are capable of handling Unicode objects and strings
3339 on input (we refer to them as strings in the descriptions) and return
3340 Unicode objects or integers as apporpriate.
3342 They all return
\NULL{} or -
1 in case an exception occurrs.
3344 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Concat
}{PyObject *left,
3346 Concat two strings giving a new Unicode string.
3349 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Split
}{PyObject *s,
3352 Split a string giving a list of Unicode strings.
3354 If sep is NULL, splitting will be done at all whitespace
3355 substrings. Otherwise, splits occur at the given separator.
3357 At most maxsplit splits will be done. If negative, no limit is set.
3359 Separators are not included in the resulting list.
3362 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Splitlines
}{PyObject *s,
3364 Split a Unicode string at line breaks, returning a list of Unicode
3365 strings. CRLF is considered to be one line break. The Line break
3366 characters are not included in the resulting strings.
3369 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Translate
}{PyObject *str,
3372 Translate a string by applying a character mapping table to it and
3373 return the resulting Unicode object.
3375 The mapping table must map Unicode ordinal integers to Unicode ordinal
3376 integers or None (causing deletion of the character).
3378 Mapping tables must only provide the __getitem__ interface,
3379 e.g. dictionaries or sequences. Unmapped character ordinals (ones
3380 which cause a LookupError) are left untouched and are copied as-is.
3382 \var{errors
} has the usual meaning for codecs. It may be
\NULL{}
3383 which indicates to use the default error handling.
3386 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Join
}{PyObject *separator,
3388 Join a sequence of strings using the given separator and return
3389 the resulting Unicode string.
3392 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Tailmatch
}{PyObject *str,
3397 Return
1 if
\var{substr
} matches
\var{str
}[\var{start
}:
\var{end
}] at
3398 the given tail end (
\var{direction
} == -
1 means to do a prefix match,
3399 \var{direction
} ==
1 a suffix match),
0 otherwise.
3402 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Find
}{PyObject *str,
3407 Return the first position of
\var{substr
} in
3408 \var{str
}[\var{start
}:
\var{end
}] using the given
\var{direction
}
3409 (
\var{direction
} ==
1 means to do a forward search,
3410 \var{direction
} == -
1 a backward search),
0 otherwise.
3413 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Count
}{PyObject *str,
3417 Count the number of occurrences of
\var{substr
} in
3418 \var{str
}[\var{start
}:
\var{end
}]
3421 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Replace
}{PyObject *str,
3425 Replace at most
\var{maxcount
} occurrences of
\var{substr
} in
3426 \var{str
} with
\var{replstr
} and return the resulting Unicode object.
3427 \var{maxcount
} == -
1 means: replace all occurrences.
3430 \begin{cfuncdesc
}{int
}{PyUnicode_Compare
}{PyObject *left, PyObject *right
}
3431 Compare two strings and return -
1,
0,
1 for less than, equal,
3435 \begin{cfuncdesc
}{PyObject*
}{PyUnicode_Format
}{PyObject *format,
3437 Returns a new string object from
\var{format
} and
\var{args
}; this is
3438 analogous to
\code{\var{format
} \%\
\var{args
}}. The
3439 \var{args
} argument must be a tuple.
3442 \begin{cfuncdesc
}{int
}{PyUnicode_Contains
}{PyObject *container,
3444 Checks whether
\var{element
} is contained in
\var{container
} and
3445 returns true or false accordingly.
3447 \var{element
} has to coerce to a one element Unicode string.
\code{-
1} is
3448 returned in case of an error.
3452 \subsection{Buffer Objects
\label{bufferObjects
}}
3453 \sectionauthor{Greg Stein
}{gstein@lyra.org
}
3456 Python objects implemented in C can export a group of functions called
3457 the ``buffer
\index{buffer interface
} interface.'' These functions can
3458 be used by an object to expose its data in a raw, byte-oriented
3459 format. Clients of the object can use the buffer interface to access
3460 the object data directly, without needing to copy it first.
3462 Two examples of objects that support
3463 the buffer interface are strings and arrays. The string object exposes
3464 the character contents in the buffer interface's byte-oriented
3465 form. An array can also expose its contents, but it should be noted
3466 that array elements may be multi-byte values.
3468 An example user of the buffer interface is the file object's
3469 \method{write()
} method. Any object that can export a series of bytes
3470 through the buffer interface can be written to a file. There are a
3471 number of format codes to
\cfunction{PyArg_ParseTuple()
} that operate
3472 against an object's buffer interface, returning data from the target
3475 More information on the buffer interface is provided in the section
3476 ``Buffer Object Structures'' (section
\ref{buffer-structs
}), under
3477 the description for
\ctype{PyBufferProcs
}\ttindex{PyBufferProcs
}.
3479 A ``buffer object'' is defined in the
\file{bufferobject.h
} header
3480 (included by
\file{Python.h
}). These objects look very similar to
3481 string objects at the Python programming level: they support slicing,
3482 indexing, concatenation, and some other standard string
3483 operations. However, their data can come from one of two sources: from
3484 a block of memory, or from another object which exports the buffer
3487 Buffer objects are useful as a way to expose the data from another
3488 object's buffer interface to the Python programmer. They can also be
3489 used as a zero-copy slicing mechanism. Using their ability to
3490 reference a block of memory, it is possible to expose any data to the
3491 Python programmer quite easily. The memory could be a large, constant
3492 array in a C extension, it could be a raw block of memory for
3493 manipulation before passing to an operating system library, or it
3494 could be used to pass around structured data in its native, in-memory
3497 \begin{ctypedesc
}{PyBufferObject
}
3498 This subtype of
\ctype{PyObject
} represents a buffer object.
3501 \begin{cvardesc
}{PyTypeObject
}{PyBuffer_Type
}
3502 The instance of
\ctype{PyTypeObject
} which represents the Python
3503 buffer type; it is the same object as
\code{types.BufferType
} in the
3504 Python layer.
\withsubitem{(in module types)
}{\ttindex{BufferType
}}.
3507 \begin{cvardesc
}{int
}{Py_END_OF_BUFFER
}
3508 This constant may be passed as the
\var{size
} parameter to
3509 \cfunction{PyBuffer_FromObject()
} or
3510 \cfunction{PyBuffer_FromReadWriteObject()
}. It indicates that the new
3511 \ctype{PyBufferObject
} should refer to
\var{base
} object from the
3512 specified
\var{offset
} to the end of its exported buffer. Using this
3513 enables the caller to avoid querying the
\var{base
} object for its
3517 \begin{cfuncdesc
}{int
}{PyBuffer_Check
}{PyObject *p
}
3518 Return true if the argument has type
\cdata{PyBuffer_Type
}.
3521 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromObject
}{PyObject *base,
3522 int offset, int size
}
3523 Return a new read-only buffer object. This raises
3524 \exception{TypeError
} if
\var{base
} doesn't support the read-only
3525 buffer protocol or doesn't provide exactly one buffer segment, or it
3526 raises
\exception{ValueError
} if
\var{offset
} is less than zero. The
3527 buffer will hold a reference to the
\var{base
} object, and the
3528 buffer's contents will refer to the
\var{base
} object's buffer
3529 interface, starting as position
\var{offset
} and extending for
3530 \var{size
} bytes. If
\var{size
} is
\constant{Py_END_OF_BUFFER
}, then
3531 the new buffer's contents extend to the length of the
3532 \var{base
} object's exported buffer data.
3535 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromReadWriteObject
}{PyObject *base,
3538 Return a new writable buffer object. Parameters and exceptions are
3539 similar to those for
\cfunction{PyBuffer_FromObject()
}.
3540 If the
\var{base
} object does not export the writeable buffer
3541 protocol, then
\exception{TypeError
} is raised.
3544 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromMemory
}{void *ptr, int size
}
3545 Return a new read-only buffer object that reads from a specified
3546 location in memory, with a specified size.
3547 The caller is responsible for ensuring that the memory buffer, passed
3548 in as
\var{ptr
}, is not deallocated while the returned buffer object
3549 exists. Raises
\exception{ValueError
} if
\var{size
} is less than
3550 zero. Note that
\constant{Py_END_OF_BUFFER
} may
\emph{not
} be passed
3551 for the
\var{size
} parameter;
\exception{ValueError
} will be raised in
3555 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_FromReadWriteMemory
}{void *ptr, int size
}
3556 Similar to
\cfunction{PyBuffer_FromMemory()
}, but the returned buffer
3560 \begin{cfuncdesc
}{PyObject*
}{PyBuffer_New
}{int size
}
3561 Returns a new writable buffer object that maintains its own memory
3562 buffer of
\var{size
} bytes.
\exception{ValueError
} is returned if
3563 \var{size
} is not zero or positive.
3567 \subsection{Tuple Objects
\label{tupleObjects
}}
3570 \begin{ctypedesc
}{PyTupleObject
}
3571 This subtype of
\ctype{PyObject
} represents a Python tuple object.
3574 \begin{cvardesc
}{PyTypeObject
}{PyTuple_Type
}
3575 This instance of
\ctype{PyTypeObject
} represents the Python tuple
3576 type; it is the same object as
\code{types.TupleType
} in the Python
3577 layer.
\withsubitem{(in module types)
}{\ttindex{TupleType
}}.
3580 \begin{cfuncdesc
}{int
}{PyTuple_Check
}{PyObject *p
}
3581 Return true if the argument is a tuple object.
3584 \begin{cfuncdesc
}{PyObject*
}{PyTuple_New
}{int len
}
3585 Return a new tuple object of size
\var{len
}, or
\NULL{} on failure.
3588 \begin{cfuncdesc
}{int
}{PyTuple_Size
}{PyObject *p
}
3589 Takes a pointer to a tuple object, and returns the size
3593 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GetItem
}{PyObject *p, int pos
}
3594 Returns the object at position
\var{pos
} in the tuple pointed
3595 to by
\var{p
}. If
\var{pos
} is out of bounds, returns
\NULL{} and
3596 sets an
\exception{IndexError
} exception.
3599 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GET_ITEM
}{PyObject *p, int pos
}
3600 Like
\cfunction{PyTuple_GetItem()
}, but does no checking of its
3604 \begin{cfuncdesc
}{PyObject*
}{PyTuple_GetSlice
}{PyObject *p,
3606 Takes a slice of the tuple pointed to by
\var{p
} from
3607 \var{low
} to
\var{high
} and returns it as a new tuple.
3610 \begin{cfuncdesc
}{int
}{PyTuple_SetItem
}{PyObject *p,
3611 int pos, PyObject *o
}
3612 Inserts a reference to object
\var{o
} at position
\var{pos
} of
3613 the tuple pointed to by
\var{p
}. It returns
\code{0} on success.
3614 \strong{Note:
} This function ``steals'' a reference to
\var{o
}.
3617 \begin{cfuncdesc
}{void
}{PyTuple_SET_ITEM
}{PyObject *p,
3618 int pos, PyObject *o
}
3619 Like
\cfunction{PyTuple_SetItem()
}, but does no error checking, and
3620 should
\emph{only
} be used to fill in brand new tuples.
3621 \strong{Note:
} This function ``steals'' a reference to
\var{o
}.
3624 \begin{cfuncdesc
}{int
}{_PyTuple_Resize
}{PyObject **p, int newsize
}
3625 Can be used to resize a tuple.
\var{newsize
} will be the new length
3626 of the tuple. Because tuples are
\emph{supposed
} to be immutable,
3627 this should only be used if there is only one reference to the object.
3628 Do
\emph{not
} use this if the tuple may already be known to some other
3629 part of the code. The tuple will always grow or shrink at the end.
3630 Think of this as destroying the old tuple and creating a new one, only
3631 more efficiently. Returns
\code{0} on success. Client code should
3632 never assume that the resulting value of
\code{*
\var{p
}} will be the
3633 same as before calling this function. If the object referenced by
3634 \code{*
\var{p
}} is replaced, the original
\code{*
\var{p
}} is
3635 destroyed. On failure, returns
\code{-
1} and sets
\code{*
\var{p
}} to
3636 \NULL, and raises
\exception{MemoryError
} or
\exception{SystemError
}.
3637 \versionchanged[Removed unused third parameter,
\var{last_is_sticky
}]{2.2}
3641 \subsection{List Objects
\label{listObjects
}}
3644 \begin{ctypedesc
}{PyListObject
}
3645 This subtype of
\ctype{PyObject
} represents a Python list object.
3648 \begin{cvardesc
}{PyTypeObject
}{PyList_Type
}
3649 This instance of
\ctype{PyTypeObject
} represents the Python list
3650 type. This is the same object as
\code{types.ListType
}.
3651 \withsubitem{(in module types)
}{\ttindex{ListType
}}
3654 \begin{cfuncdesc
}{int
}{PyList_Check
}{PyObject *p
}
3655 Returns true if its argument is a
\ctype{PyListObject
}.
3658 \begin{cfuncdesc
}{PyObject*
}{PyList_New
}{int len
}
3659 Returns a new list of length
\var{len
} on success, or
\NULL{} on
3663 \begin{cfuncdesc
}{int
}{PyList_Size
}{PyObject *list
}
3664 Returns the length of the list object in
\var{list
}; this is
3665 equivalent to
\samp{len(
\var{list
})
} on a list object.
3669 \begin{cfuncdesc
}{int
}{PyList_GET_SIZE
}{PyObject *list
}
3670 Macro form of
\cfunction{PyList_Size()
} without error checking.
3673 \begin{cfuncdesc
}{PyObject*
}{PyList_GetItem
}{PyObject *list, int index
}
3674 Returns the object at position
\var{pos
} in the list pointed
3675 to by
\var{p
}. If
\var{pos
} is out of bounds, returns
\NULL{} and
3676 sets an
\exception{IndexError
} exception.
3679 \begin{cfuncdesc
}{PyObject*
}{PyList_GET_ITEM
}{PyObject *list, int i
}
3680 Macro form of
\cfunction{PyList_GetItem()
} without error checking.
3683 \begin{cfuncdesc
}{int
}{PyList_SetItem
}{PyObject *list, int index,
3685 Sets the item at index
\var{index
} in list to
\var{item
}.
3686 Returns
\code{0} on success or
\code{-
1} on failure.
3687 \strong{Note:
} This function ``steals'' a reference to
\var{item
} and
3688 discards a reference to an item already in the list at the affected
3692 \begin{cfuncdesc
}{void
}{PyList_SET_ITEM
}{PyObject *list, int i,
3694 Macro form of
\cfunction{PyList_SetItem()
} without error checking.
3695 \strong{Note:
} This function ``steals'' a reference to
\var{item
},
3696 and, unlike
\cfunction{PyList_SetItem()
}, does
\emph{not
} discard a
3697 reference to any item that it being replaced; any reference in
3698 \var{list
} at position
\var{i
} will be leaked. This is normally only
3699 used to fill in new lists where there is no previous content.
3702 \begin{cfuncdesc
}{int
}{PyList_Insert
}{PyObject *list, int index,
3704 Inserts the item
\var{item
} into list
\var{list
} in front of index
3705 \var{index
}. Returns
\code{0} if successful; returns
\code{-
1} and
3706 raises an exception if unsuccessful. Analogous to
3707 \code{\var{list
}.insert(
\var{index
},
\var{item
})
}.
3710 \begin{cfuncdesc
}{int
}{PyList_Append
}{PyObject *list, PyObject *item
}
3711 Appends the object
\var{item
} at the end of list
\var{list
}. Returns
3712 \code{0} if successful; returns
\code{-
1} and sets an exception if
3713 unsuccessful. Analogous to
\code{\var{list
}.append(
\var{item
})
}.
3716 \begin{cfuncdesc
}{PyObject*
}{PyList_GetSlice
}{PyObject *list,
3718 Returns a list of the objects in
\var{list
} containing the objects
3719 \emph{between
} \var{low
} and
\var{high
}. Returns NULL and sets an
3720 exception if unsuccessful.
3721 Analogous to
\code{\var{list
}[\var{low
}:
\var{high
}]}.
3724 \begin{cfuncdesc
}{int
}{PyList_SetSlice
}{PyObject *list,
3727 Sets the slice of
\var{list
} between
\var{low
} and
\var{high
} to the
3728 contents of
\var{itemlist
}. Analogous to
3729 \code{\var{list
}[\var{low
}:
\var{high
}] =
\var{itemlist
}}. Returns
3730 \code{0} on success,
\code{-
1} on failure.
3733 \begin{cfuncdesc
}{int
}{PyList_Sort
}{PyObject *list
}
3734 Sorts the items of
\var{list
} in place. Returns
\code{0} on success,
3735 \code{-
1} on failure. This is equivalent to
3736 \samp{\var{list
}.sort()
}.
3739 \begin{cfuncdesc
}{int
}{PyList_Reverse
}{PyObject *list
}
3740 Reverses the items of
\var{list
} in place. Returns
\code{0} on
3741 success,
\code{-
1} on failure. This is the equivalent of
3742 \samp{\var{list
}.reverse()
}.
3745 \begin{cfuncdesc
}{PyObject*
}{PyList_AsTuple
}{PyObject *list
}
3746 Returns a new tuple object containing the contents of
\var{list
};
3747 equivalent to
\samp{tuple(
\var{list
})
}.
\bifuncindex{tuple
}
3751 \section{Mapping Objects
\label{mapObjects
}}
3756 \subsection{Dictionary Objects
\label{dictObjects
}}
3758 \obindex{dictionary
}
3759 \begin{ctypedesc
}{PyDictObject
}
3760 This subtype of
\ctype{PyObject
} represents a Python dictionary object.
3763 \begin{cvardesc
}{PyTypeObject
}{PyDict_Type
}
3764 This instance of
\ctype{PyTypeObject
} represents the Python dictionary
3765 type. This is exposed to Python programs as
\code{types.DictType
} and
3766 \code{types.DictionaryType
}.
3767 \withsubitem{(in module types)
}{\ttindex{DictType
}\ttindex{DictionaryType
}}
3770 \begin{cfuncdesc
}{int
}{PyDict_Check
}{PyObject *p
}
3771 Returns true if its argument is a
\ctype{PyDictObject
}.
3774 \begin{cfuncdesc
}{PyObject*
}{PyDict_New
}{}
3775 Returns a new empty dictionary, or
\NULL{} on failure.
3778 \begin{cfuncdesc
}{void
}{PyDict_Clear
}{PyObject *p
}
3779 Empties an existing dictionary of all key-value pairs.
3782 \begin{cfuncdesc
}{PyObject*
}{PyDict_Copy
}{PyObject *p
}
3783 Returns a new dictionary that contains the same key-value pairs as p.
3784 Empties an existing dictionary of all key-value pairs.
3788 \begin{cfuncdesc
}{int
}{PyDict_SetItem
}{PyObject *p, PyObject *key,
3790 Inserts
\var{value
} into the dictionary
\var{p
} with a key of
\var{key
}.
3791 \var{key
} must be hashable; if it isn't,
\exception{TypeError
} will be
3793 Returns
\code{0} on success or
\code{-
1} on failure.
3796 \begin{cfuncdesc
}{int
}{PyDict_SetItemString
}{PyObject *p,
3799 Inserts
\var{value
} into the dictionary
\var{p
} using
\var{key
}
3800 as a key.
\var{key
} should be a
\ctype{char*
}. The key object is
3801 created using
\code{PyString_FromString(
\var{key
})
}.
3802 Returns
\code{0} on success or
\code{-
1} on failure.
3803 \ttindex{PyString_FromString()
}
3806 \begin{cfuncdesc
}{int
}{PyDict_DelItem
}{PyObject *p, PyObject *key
}
3807 Removes the entry in dictionary
\var{p
} with key
\var{key
}.
3808 \var{key
} must be hashable; if it isn't,
\exception{TypeError
} is
3812 \begin{cfuncdesc
}{int
}{PyDict_DelItemString
}{PyObject *p, char *key
}
3813 Removes the entry in dictionary
\var{p
} which has a key
3814 specified by the string
\var{key
}.
3815 Returns
\code{0} on success or
\code{-
1} on failure.
3818 \begin{cfuncdesc
}{PyObject*
}{PyDict_GetItem
}{PyObject *p, PyObject *key
}
3819 Returns the object from dictionary
\var{p
} which has a key
3820 \var{key
}. Returns
\NULL{} if the key
\var{key
} is not present, but
3821 \emph{without
} setting an exception.
3824 \begin{cfuncdesc
}{PyObject*
}{PyDict_GetItemString
}{PyObject *p, char *key
}
3825 This is the same as
\cfunction{PyDict_GetItem()
}, but
\var{key
} is
3826 specified as a
\ctype{char*
}, rather than a
\ctype{PyObject*
}.
3829 \begin{cfuncdesc
}{PyObject*
}{PyDict_Items
}{PyObject *p
}
3830 Returns a
\ctype{PyListObject
} containing all the items
3831 from the dictionary, as in the dictinoary method
\method{items()
} (see
3832 the
\citetitle[../lib/lib.html
]{Python Library Reference
}).
3835 \begin{cfuncdesc
}{PyObject*
}{PyDict_Keys
}{PyObject *p
}
3836 Returns a
\ctype{PyListObject
} containing all the keys
3837 from the dictionary, as in the dictionary method
\method{keys()
} (see the
3838 \citetitle[../lib/lib.html
]{Python Library Reference
}).
3841 \begin{cfuncdesc
}{PyObject*
}{PyDict_Values
}{PyObject *p
}
3842 Returns a
\ctype{PyListObject
} containing all the values
3843 from the dictionary
\var{p
}, as in the dictionary method
3844 \method{values()
} (see the
\citetitle[../lib/lib.html
]{Python Library
3848 \begin{cfuncdesc
}{int
}{PyDict_Size
}{PyObject *p
}
3849 Returns the number of items in the dictionary. This is equivalent to
3850 \samp{len(
\var{p
})
} on a dictionary.
\bifuncindex{len
}
3853 \begin{cfuncdesc
}{int
}{PyDict_Next
}{PyObject *p, int *ppos,
3854 PyObject **pkey, PyObject **pvalue
}
3855 Iterate over all key-value pairs in the dictionary
\var{p
}. The
3856 \ctype{int
} referred to by
\var{ppos
} must be initialized to
\code{0}
3857 prior to the first call to this function to start the iteration; the
3858 function returns true for each pair in the dictionary, and false once
3859 all pairs have been reported. The parameters
\var{pkey
} and
3860 \var{pvalue
} should either point to
\ctype{PyObject*
} variables that
3861 will be filled in with each key and value, respectively, or may be
3867 PyObject *key, *value;
3870 while (PyDict_Next(self->dict, &pos, &key, &value))
{
3871 /* do something interesting with the values... */
3876 The dictionary
\var{p
} should not be mutated during iteration. It is
3877 safe (since Python
2.1) to modify the values of the keys as you
3878 iterate over the dictionary, but only so long as the set of keys does
3879 not change. For example:
3882 PyObject *key, *value;
3885 while (PyDict_Next(self->dict, &pos, &key, &value))
{
3886 int i = PyInt_AS_LONG(value) +
1;
3887 PyObject *o = PyInt_FromLong(i);
3890 if (PyDict_SetItem(self->dict, key, o) <
0)
{
3899 \begin{cfuncdesc
}{int
}{PyDict_Merge
}{PyObject *a, PyObject *b, int override
}
3900 Iterate over dictionary
\var{b
} adding key-value pairs to dictionary
3901 \var{a
}. If
\var{override
} is true, existing pairs in
\var{a
} will be
3902 replaced if a matching key is found in
\var{b
}, otherwise pairs will
3903 only be added if there is not a matching key in
\var{a
}. Returns
3904 \code{0} on success or
\code{-
1} if an exception was raised.
3908 \begin{cfuncdesc
}{int
}{PyDict_Update
}{PyObject *a, PyObject *b
}
3909 This is the same as
\code{PyDict_Merge(
\var{a
},
\var{b
},
1)
} in C, or
3910 \code{\var{a
}.update(
\var{b
})
} in Python. Returns
\code{0} on success
3911 or
\code{-
1} if an exception was raised.
3916 \section{Other Objects
\label{otherObjects
}}
3918 \subsection{File Objects
\label{fileObjects
}}
3921 Python's built-in file objects are implemented entirely on the
3922 \ctype{FILE*
} support from the C standard library. This is an
3923 implementation detail and may change in future releases of Python.
3925 \begin{ctypedesc
}{PyFileObject
}
3926 This subtype of
\ctype{PyObject
} represents a Python file object.
3929 \begin{cvardesc
}{PyTypeObject
}{PyFile_Type
}
3930 This instance of
\ctype{PyTypeObject
} represents the Python file
3931 type. This is exposed to Python programs as
\code{types.FileType
}.
3932 \withsubitem{(in module types)
}{\ttindex{FileType
}}
3935 \begin{cfuncdesc
}{int
}{PyFile_Check
}{PyObject *p
}
3936 Returns true if its argument is a
\ctype{PyFileObject
}.
3939 \begin{cfuncdesc
}{PyObject*
}{PyFile_FromString
}{char *filename, char *mode
}
3940 On success, returns a new file object that is opened on the
3941 file given by
\var{filename
}, with a file mode given by
\var{mode
},
3942 where
\var{mode
} has the same semantics as the standard C routine
3943 \cfunction{fopen()
}\ttindex{fopen()
}. On failure, returns
\NULL.
3946 \begin{cfuncdesc
}{PyObject*
}{PyFile_FromFile
}{FILE *fp,
3947 char *name, char *mode,
3948 int
(*close)(FILE*)}
3949 Creates a new
\ctype{PyFileObject
} from the already-open standard C
3950 file pointer,
\var{fp
}. The function
\var{close
} will be called when
3951 the file should be closed. Returns
\NULL{} on failure.
3954 \begin{cfuncdesc
}{FILE*
}{PyFile_AsFile
}{PyFileObject *p
}
3955 Returns the file object associated with
\var{p
} as a
\ctype{FILE*
}.
3958 \begin{cfuncdesc
}{PyObject*
}{PyFile_GetLine
}{PyObject *p, int n
}
3959 Equivalent to
\code{\var{p
}.readline(
\optional{\var{n
}})
}, this
3960 function reads one line from the object
\var{p
}.
\var{p
} may be a
3961 file object or any object with a
\method{readline()
} method. If
3962 \var{n
} is
\code{0}, exactly one line is read, regardless of the
3963 length of the line. If
\var{n
} is greater than
\code{0}, no more than
3964 \var{n
} bytes will be read from the file; a partial line can be
3965 returned. In both cases, an empty string is returned if the end of
3966 the file is reached immediately. If
\var{n
} is less than
\code{0},
3967 however, one line is read regardless of length, but
3968 \exception{EOFError
} is raised if the end of the file is reached
3970 \withsubitem{(built-in exception)
}{\ttindex{EOFError
}}
3973 \begin{cfuncdesc
}{PyObject*
}{PyFile_Name
}{PyObject *p
}
3974 Returns the name of the file specified by
\var{p
} as a string object.
3977 \begin{cfuncdesc
}{void
}{PyFile_SetBufSize
}{PyFileObject *p, int n
}
3978 Available on systems with
\cfunction{setvbuf()
}\ttindex{setvbuf()
}
3979 only. This should only be called immediately after file object
3983 \begin{cfuncdesc
}{int
}{PyFile_SoftSpace
}{PyObject *p, int newflag
}
3984 This function exists for internal use by the interpreter.
3985 Sets the
\member{softspace
} attribute of
\var{p
} to
\var{newflag
} and
3986 \withsubitem{(file attribute)
}{\ttindex{softspace
}}returns the
3987 previous value.
\var{p
} does not have to be a file object
3988 for this function to work properly; any object is supported (thought
3989 its only interesting if the
\member{softspace
} attribute can be set).
3990 This function clears any errors, and will return
\code{0} as the
3991 previous value if the attribute either does not exist or if there were
3992 errors in retrieving it. There is no way to detect errors from this
3993 function, but doing so should not be needed.
3996 \begin{cfuncdesc
}{int
}{PyFile_WriteObject
}{PyObject *obj, PyFileObject *p,
3998 Writes object
\var{obj
} to file object
\var{p
}. The only supported
3999 flag for
\var{flags
} is
\constant{Py_PRINT_RAW
}\ttindex{Py_PRINT_RAW
};
4000 if given, the
\function{str()
} of the object is written instead of the
4001 \function{repr()
}. Returns
\code{0} on success or
\code{-
1} on
4002 failure; the appropriate exception will be set.
4005 \begin{cfuncdesc
}{int
}{PyFile_WriteString
}{char *s, PyFileObject *p
}
4006 Writes string
\var{s
} to file object
\var{p
}. Returns
\code{0} on
4007 success or
\code{-
1} on failure; the appropriate exception will be
4012 \subsection{Instance Objects
\label{instanceObjects
}}
4015 There are very few functions specific to instance objects.
4017 \begin{cvardesc
}{PyTypeObject
}{PyInstance_Type
}
4018 Type object for class instances.
4021 \begin{cfuncdesc
}{int
}{PyInstance_Check
}{PyObject *obj
}
4022 Returns true if
\var{obj
} is an instance.
4025 \begin{cfuncdesc
}{PyObject*
}{PyInstance_New
}{PyObject *class,
4028 Create a new instance of a specific class. The parameters
\var{arg
}
4029 and
\var{kw
} are used as the positional and keyword parameters to
4030 the object's constructor.
4033 \begin{cfuncdesc
}{PyObject*
}{PyInstance_NewRaw
}{PyObject *class,
4035 Create a new instance of a specific class without calling it's
4036 constructor.
\var{class
} is the class of new object. The
4037 \var{dict
} parameter will be used as the object's
\member{__dict__
};
4038 if
\NULL, a new dictionary will be created for the instance.
4042 \subsection{Module Objects
\label{moduleObjects
}}
4045 There are only a few functions special to module objects.
4047 \begin{cvardesc
}{PyTypeObject
}{PyModule_Type
}
4048 This instance of
\ctype{PyTypeObject
} represents the Python module
4049 type. This is exposed to Python programs as
\code{types.ModuleType
}.
4050 \withsubitem{(in module types)
}{\ttindex{ModuleType
}}
4053 \begin{cfuncdesc
}{int
}{PyModule_Check
}{PyObject *p
}
4054 Returns true if its argument is a module object.
4057 \begin{cfuncdesc
}{PyObject*
}{PyModule_New
}{char *name
}
4058 Return a new module object with the
\member{__name__
} attribute set to
4059 \var{name
}. Only the module's
\member{__doc__
} and
4060 \member{__name__
} attributes are filled in; the caller is responsible
4061 for providing a
\member{__file__
} attribute.
4062 \withsubitem{(module attribute)
}{
4063 \ttindex{__name__
}\ttindex{__doc__
}\ttindex{__file__
}}
4066 \begin{cfuncdesc
}{PyObject*
}{PyModule_GetDict
}{PyObject *module
}
4067 Return the dictionary object that implements
\var{module
}'s namespace;
4068 this object is the same as the
\member{__dict__
} attribute of the
4069 module object. This function never fails.
4070 \withsubitem{(module attribute)
}{\ttindex{__dict__
}}
4073 \begin{cfuncdesc
}{char*
}{PyModule_GetName
}{PyObject *module
}
4074 Return
\var{module
}'s
\member{__name__
} value. If the module does not
4075 provide one, or if it is not a string,
\exception{SystemError
} is
4076 raised and
\NULL{} is returned.
4077 \withsubitem{(module attribute)
}{\ttindex{__name__
}}
4078 \withsubitem{(built-in exception)
}{\ttindex{SystemError
}}
4081 \begin{cfuncdesc
}{char*
}{PyModule_GetFilename
}{PyObject *module
}
4082 Return the name of the file from which
\var{module
} was loaded using
4083 \var{module
}'s
\member{__file__
} attribute. If this is not defined,
4084 or if it is not a string, raise
\exception{SystemError
} and return
4086 \withsubitem{(module attribute)
}{\ttindex{__file__
}}
4087 \withsubitem{(built-in exception)
}{\ttindex{SystemError
}}
4090 \begin{cfuncdesc
}{int
}{PyModule_AddObject
}{PyObject *module,
4091 char *name, PyObject *value
}
4092 Add an object to
\var{module
} as
\var{name
}. This is a convenience
4093 function which can be used from the module's initialization function.
4094 This steals a reference to
\var{value
}. Returns
\code{-
1} on error,
4095 \code{0} on success.
4099 \begin{cfuncdesc
}{int
}{PyModule_AddIntConstant
}{PyObject *module,
4100 char *name, int value
}
4101 Add an integer constant to
\var{module
} as
\var{name
}. This convenience
4102 function can be used from the module's initialization function.
4103 Returns
\code{-
1} on error,
\code{0} on success.
4107 \begin{cfuncdesc
}{int
}{PyModule_AddStringConstant
}{PyObject *module,
4108 char *name, char *value
}
4109 Add a string constant to
\var{module
} as
\var{name
}. This convenience
4110 function can be used from the module's initialization function. The
4111 string
\var{value
} must be null-terminated. Returns
\code{-
1} on
4112 error,
\code{0} on success.
4117 \subsection{CObjects
\label{cObjects
}}
4120 Refer to
\emph{Extending and Embedding the Python Interpreter
},
4121 section
1.12 (``Providing a C API for an Extension Module''), for more
4122 information on using these objects.
4125 \begin{ctypedesc
}{PyCObject
}
4126 This subtype of
\ctype{PyObject
} represents an opaque value, useful for
4127 C extension modules who need to pass an opaque value (as a
4128 \ctype{void*
} pointer) through Python code to other C code. It is
4129 often used to make a C function pointer defined in one module
4130 available to other modules, so the regular import mechanism can be
4131 used to access C APIs defined in dynamically loaded modules.
4134 \begin{cfuncdesc
}{int
}{PyCObject_Check
}{PyObject *p
}
4135 Returns true if its argument is a
\ctype{PyCObject
}.
4138 \begin{cfuncdesc
}{PyObject*
}{PyCObject_FromVoidPtr
}{void* cobj,
4139 void
(*destr)(void *)}
4140 Creates a
\ctype{PyCObject
} from the
\code{void *
}\var{cobj
}. The
4141 \var{destr
} function will be called when the object is reclaimed, unless
4145 \begin{cfuncdesc
}{PyObject*
}{PyCObject_FromVoidPtrAndDesc
}{void* cobj,
4146 void* desc, void
(*destr)(void *, void *) }
4147 Creates a
\ctype{PyCObject
} from the
\ctype{void *
}\var{cobj
}. The
4148 \var{destr
} function will be called when the object is reclaimed. The
4149 \var{desc
} argument can be used to pass extra callback data for the
4150 destructor function.
4153 \begin{cfuncdesc
}{void*
}{PyCObject_AsVoidPtr
}{PyObject* self
}
4154 Returns the object
\ctype{void *
} that the
4155 \ctype{PyCObject
} \var{self
} was created with.
4158 \begin{cfuncdesc
}{void*
}{PyCObject_GetDesc
}{PyObject* self
}
4159 Returns the description
\ctype{void *
} that the
4160 \ctype{PyCObject
} \var{self
} was created with.
4164 \chapter{Initialization, Finalization, and Threads
4165 \label{initialization
}}
4167 \begin{cfuncdesc
}{void
}{Py_Initialize
}{}
4168 Initialize the Python interpreter. In an application embedding
4169 Python, this should be called before using any other Python/C API
4170 functions; with the exception of
4171 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
},
4172 \cfunction{PyEval_InitThreads()
}\ttindex{PyEval_InitThreads()
},
4173 \cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
},
4174 and
\cfunction{PyEval_AcquireLock()
}\ttindex{PyEval_AcquireLock()
}.
4175 This initializes the table of loaded modules (
\code{sys.modules
}), and
4176 \withsubitem{(in module sys)
}{\ttindex{modules
}\ttindex{path
}}creates the
4177 fundamental modules
\module{__builtin__
}\refbimodindex{__builtin__
},
4178 \module{__main__
}\refbimodindex{__main__
} and
4179 \module{sys
}\refbimodindex{sys
}. It also initializes the module
4180 search
\indexiii{module
}{search
}{path
} path (
\code{sys.path
}).
4181 It does not set
\code{sys.argv
}; use
4182 \cfunction{PySys_SetArgv()
}\ttindex{PySys_SetArgv()
} for that. This
4183 is a no-op when called for a second time (without calling
4184 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} first). There is no
4185 return value; it is a fatal error if the initialization fails.
4188 \begin{cfuncdesc
}{int
}{Py_IsInitialized
}{}
4189 Return true (nonzero) when the Python interpreter has been
4190 initialized, false (zero) if not. After
\cfunction{Py_Finalize()
} is
4191 called, this returns false until
\cfunction{Py_Initialize()
} is called
4195 \begin{cfuncdesc
}{void
}{Py_Finalize
}{}
4196 Undo all initializations made by
\cfunction{Py_Initialize()
} and
4197 subsequent use of Python/C API functions, and destroy all
4198 sub-interpreters (see
\cfunction{Py_NewInterpreter()
} below) that were
4199 created and not yet destroyed since the last call to
4200 \cfunction{Py_Initialize()
}. Ideally, this frees all memory allocated
4201 by the Python interpreter. This is a no-op when called for a second
4202 time (without calling
\cfunction{Py_Initialize()
} again first). There
4203 is no return value; errors during finalization are ignored.
4205 This function is provided for a number of reasons. An embedding
4206 application might want to restart Python without having to restart the
4207 application itself. An application that has loaded the Python
4208 interpreter from a dynamically loadable library (or DLL) might want to
4209 free all memory allocated by Python before unloading the DLL. During a
4210 hunt for memory leaks in an application a developer might want to free
4211 all memory allocated by Python before exiting from the application.
4213 \strong{Bugs and caveats:
} The destruction of modules and objects in
4214 modules is done in random order; this may cause destructors
4215 (
\method{__del__()
} methods) to fail when they depend on other objects
4216 (even functions) or modules. Dynamically loaded extension modules
4217 loaded by Python are not unloaded. Small amounts of memory allocated
4218 by the Python interpreter may not be freed (if you find a leak, please
4219 report it). Memory tied up in circular references between objects is
4220 not freed. Some memory allocated by extension modules may not be
4221 freed. Some extension may not work properly if their initialization
4222 routine is called more than once; this can happen if an applcation
4223 calls
\cfunction{Py_Initialize()
} and
\cfunction{Py_Finalize()
} more
4227 \begin{cfuncdesc
}{PyThreadState*
}{Py_NewInterpreter
}{}
4228 Create a new sub-interpreter. This is an (almost) totally separate
4229 environment for the execution of Python code. In particular, the new
4230 interpreter has separate, independent versions of all imported
4231 modules, including the fundamental modules
4232 \module{__builtin__
}\refbimodindex{__builtin__
},
4233 \module{__main__
}\refbimodindex{__main__
} and
4234 \module{sys
}\refbimodindex{sys
}. The table of loaded modules
4235 (
\code{sys.modules
}) and the module search path (
\code{sys.path
}) are
4236 also separate. The new environment has no
\code{sys.argv
} variable.
4237 It has new standard I/O stream file objects
\code{sys.stdin
},
4238 \code{sys.stdout
} and
\code{sys.stderr
} (however these refer to the
4239 same underlying
\ctype{FILE
} structures in the C library).
4240 \withsubitem{(in module sys)
}{
4241 \ttindex{stdout
}\ttindex{stderr
}\ttindex{stdin
}}
4243 The return value points to the first thread state created in the new
4244 sub-interpreter. This thread state is made the current thread state.
4245 Note that no actual thread is created; see the discussion of thread
4246 states below. If creation of the new interpreter is unsuccessful,
4247 \NULL{} is returned; no exception is set since the exception state
4248 is stored in the current thread state and there may not be a current
4249 thread state. (Like all other Python/C API functions, the global
4250 interpreter lock must be held before calling this function and is
4251 still held when it returns; however, unlike most other Python/C API
4252 functions, there needn't be a current thread state on entry.)
4254 Extension modules are shared between (sub-)interpreters as follows:
4255 the first time a particular extension is imported, it is initialized
4256 normally, and a (shallow) copy of its module's dictionary is
4257 squirreled away. When the same extension is imported by another
4258 (sub-)interpreter, a new module is initialized and filled with the
4259 contents of this copy; the extension's
\code{init
} function is not
4260 called. Note that this is different from what happens when an
4261 extension is imported after the interpreter has been completely
4262 re-initialized by calling
4263 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} and
4264 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
}; in that case,
4265 the extension's
\code{init
\var{module
}} function
\emph{is
} called
4268 \strong{Bugs and caveats:
} Because sub-interpreters (and the main
4269 interpreter) are part of the same process, the insulation between them
4270 isn't perfect --- for example, using low-level file operations like
4271 \withsubitem{(in module os)
}{\ttindex{close()
}}
4272 \function{os.close()
} they can (accidentally or maliciously) affect each
4273 other's open files. Because of the way extensions are shared between
4274 (sub-)interpreters, some extensions may not work properly; this is
4275 especially likely when the extension makes use of (static) global
4276 variables, or when the extension manipulates its module's dictionary
4277 after its initialization. It is possible to insert objects created in
4278 one sub-interpreter into a namespace of another sub-interpreter; this
4279 should be done with great care to avoid sharing user-defined
4280 functions, methods, instances or classes between sub-interpreters,
4281 since import operations executed by such objects may affect the
4282 wrong (sub-)interpreter's dictionary of loaded modules. (XXX This is
4283 a hard-to-fix bug that will be addressed in a future release.)
4286 \begin{cfuncdesc
}{void
}{Py_EndInterpreter
}{PyThreadState *tstate
}
4287 Destroy the (sub-)interpreter represented by the given thread state.
4288 The given thread state must be the current thread state. See the
4289 discussion of thread states below. When the call returns, the current
4290 thread state is
\NULL{}. All thread states associated with this
4291 interpreted are destroyed. (The global interpreter lock must be held
4292 before calling this function and is still held when it returns.)
4293 \cfunction{Py_Finalize()
}\ttindex{Py_Finalize()
} will destroy all
4294 sub-interpreters that haven't been explicitly destroyed at that point.
4297 \begin{cfuncdesc
}{void
}{Py_SetProgramName
}{char *name
}
4298 This function should be called before
4299 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
} is called
4300 for the first time, if it is called at all. It tells the interpreter
4301 the value of the
\code{argv
[0]} argument to the
4302 \cfunction{main()
}\ttindex{main()
} function of the program. This is
4303 used by
\cfunction{Py_GetPath()
}\ttindex{Py_GetPath()
} and some other
4304 functions below to find the Python run-time libraries relative to the
4305 interpreter executable. The default value is
\code{'python'
}. The
4306 argument should point to a zero-terminated character string in static
4307 storage whose contents will not change for the duration of the
4308 program's execution. No code in the Python interpreter will change
4309 the contents of this storage.
4312 \begin{cfuncdesc
}{char*
}{Py_GetProgramName
}{}
4313 Return the program name set with
4314 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
}, or the
4315 default. The returned string points into static storage; the caller
4316 should not modify its value.
4319 \begin{cfuncdesc
}{char*
}{Py_GetPrefix
}{}
4320 Return the
\emph{prefix
} for installed platform-independent files. This
4321 is derived through a number of complicated rules from the program name
4322 set with
\cfunction{Py_SetProgramName()
} and some environment variables;
4323 for example, if the program name is
\code{'/usr/local/bin/python'
},
4324 the prefix is
\code{'/usr/local'
}. The returned string points into
4325 static storage; the caller should not modify its value. This
4326 corresponds to the
\makevar{prefix
} variable in the top-level
4327 \file{Makefile
} and the
\longprogramopt{prefix
} argument to the
4328 \program{configure
} script at build time. The value is available to
4329 Python code as
\code{sys.prefix
}. It is only useful on
\UNIX{}. See
4330 also the next function.
4333 \begin{cfuncdesc
}{char*
}{Py_GetExecPrefix
}{}
4334 Return the
\emph{exec-prefix
} for installed platform-
\emph{de
}pendent
4335 files. This is derived through a number of complicated rules from the
4336 program name set with
\cfunction{Py_SetProgramName()
} and some environment
4337 variables; for example, if the program name is
4338 \code{'/usr/local/bin/python'
}, the exec-prefix is
4339 \code{'/usr/local'
}. The returned string points into static storage;
4340 the caller should not modify its value. This corresponds to the
4341 \makevar{exec_prefix
} variable in the top-level
\file{Makefile
} and the
4342 \longprogramopt{exec-prefix
} argument to the
4343 \program{configure
} script at build time. The value is available to
4344 Python code as
\code{sys.exec_prefix
}. It is only useful on
\UNIX{}.
4346 Background: The exec-prefix differs from the prefix when platform
4347 dependent files (such as executables and shared libraries) are
4348 installed in a different directory tree. In a typical installation,
4349 platform dependent files may be installed in the
4350 \file{/usr/local/plat
} subtree while platform independent may be
4351 installed in
\file{/usr/local
}.
4353 Generally speaking, a platform is a combination of hardware and
4354 software families, e.g. Sparc machines running the Solaris
2.x
4355 operating system are considered the same platform, but Intel machines
4356 running Solaris
2.x are another platform, and Intel machines running
4357 Linux are yet another platform. Different major revisions of the same
4358 operating system generally also form different platforms. Non-
\UNIX{}
4359 operating systems are a different story; the installation strategies
4360 on those systems are so different that the prefix and exec-prefix are
4361 meaningless, and set to the empty string. Note that compiled Python
4362 bytecode files are platform independent (but not independent from the
4363 Python version by which they were compiled!).
4365 System administrators will know how to configure the
\program{mount
} or
4366 \program{automount
} programs to share
\file{/usr/local
} between platforms
4367 while having
\file{/usr/local/plat
} be a different filesystem for each
4371 \begin{cfuncdesc
}{char*
}{Py_GetProgramFullPath
}{}
4372 Return the full program name of the Python executable; this is
4373 computed as a side-effect of deriving the default module search path
4374 from the program name (set by
4375 \cfunction{Py_SetProgramName()
}\ttindex{Py_SetProgramName()
} above).
4376 The returned string points into static storage; the caller should not
4377 modify its value. The value is available to Python code as
4378 \code{sys.executable
}.
4379 \withsubitem{(in module sys)
}{\ttindex{executable
}}
4382 \begin{cfuncdesc
}{char*
}{Py_GetPath
}{}
4383 \indexiii{module
}{search
}{path
}
4384 Return the default module search path; this is computed from the
4385 program name (set by
\cfunction{Py_SetProgramName()
} above) and some
4386 environment variables. The returned string consists of a series of
4387 directory names separated by a platform dependent delimiter character.
4388 The delimiter character is
\character{:
} on
\UNIX{},
\character{;
} on
4389 DOS/Windows, and
\character{\e n
} (the
\ASCII{} newline character) on
4390 Macintosh. The returned string points into static storage; the caller
4391 should not modify its value. The value is available to Python code
4392 as the list
\code{sys.path
}\withsubitem{(in module sys)
}{\ttindex{path
}},
4393 which may be modified to change the future search path for loaded
4396 % XXX should give the exact rules
4399 \begin{cfuncdesc
}{const char*
}{Py_GetVersion
}{}
4400 Return the version of this Python interpreter. This is a string that
4401 looks something like
4404 "
1.5 (
#67, Dec
31 1997,
22:
34:
28)
[GCC
2.7.2.2]"
4407 The first word (up to the first space character) is the current Python
4408 version; the first three characters are the major and minor version
4409 separated by a period. The returned string points into static storage;
4410 the caller should not modify its value. The value is available to
4411 Python code as the list
\code{sys.version
}.
4412 \withsubitem{(in module sys)
}{\ttindex{version
}}
4415 \begin{cfuncdesc
}{const char*
}{Py_GetPlatform
}{}
4416 Return the platform identifier for the current platform. On
\UNIX{},
4417 this is formed from the ``official'' name of the operating system,
4418 converted to lower case, followed by the major revision number; e.g.,
4419 for Solaris
2.x, which is also known as SunOS
5.x, the value is
4420 \code{'sunos5'
}. On Macintosh, it is
\code{'mac'
}. On Windows, it
4421 is
\code{'win'
}. The returned string points into static storage;
4422 the caller should not modify its value. The value is available to
4423 Python code as
\code{sys.platform
}.
4424 \withsubitem{(in module sys)
}{\ttindex{platform
}}
4427 \begin{cfuncdesc
}{const char*
}{Py_GetCopyright
}{}
4428 Return the official copyright string for the current Python version,
4431 \code{'Copyright
1991-
1995 Stichting Mathematisch Centrum, Amsterdam'
}
4433 The returned string points into static storage; the caller should not
4434 modify its value. The value is available to Python code as the list
4435 \code{sys.copyright
}.
4436 \withsubitem{(in module sys)
}{\ttindex{copyright
}}
4439 \begin{cfuncdesc
}{const char*
}{Py_GetCompiler
}{}
4440 Return an indication of the compiler used to build the current Python
4441 version, in square brackets, for example:
4447 The returned string points into static storage; the caller should not
4448 modify its value. The value is available to Python code as part of
4449 the variable
\code{sys.version
}.
4450 \withsubitem{(in module sys)
}{\ttindex{version
}}
4453 \begin{cfuncdesc
}{const char*
}{Py_GetBuildInfo
}{}
4454 Return information about the sequence number and build date and time
4455 of the current Python interpreter instance, for example
4458 "
#67, Aug
1 1997,
22:
34:
28"
4461 The returned string points into static storage; the caller should not
4462 modify its value. The value is available to Python code as part of
4463 the variable
\code{sys.version
}.
4464 \withsubitem{(in module sys)
}{\ttindex{version
}}
4467 \begin{cfuncdesc
}{int
}{PySys_SetArgv
}{int argc, char **argv
}
4468 Set
\code{sys.argv
} based on
\var{argc
} and
\var{argv
}. These
4469 parameters are similar to those passed to the program's
4470 \cfunction{main()
}\ttindex{main()
} function with the difference that
4471 the first entry should refer to the script file to be executed rather
4472 than the executable hosting the Python interpreter. If there isn't a
4473 script that will be run, the first entry in
\var{argv
} can be an empty
4474 string. If this function fails to initialize
\code{sys.argv
}, a fatal
4475 condition is signalled using
4476 \cfunction{Py_FatalError()
}\ttindex{Py_FatalError()
}.
4477 \withsubitem{(in module sys)
}{\ttindex{argv
}}
4478 % XXX impl. doesn't seem consistent in allowing 0/NULL for the params;
4482 % XXX Other PySys thingies (doesn't really belong in this chapter)
4484 \section{Thread State and the Global Interpreter Lock
4487 \index{global interpreter lock
}
4488 \index{interpreter lock
}
4489 \index{lock, interpreter
}
4491 The Python interpreter is not fully thread safe. In order to support
4492 multi-threaded Python programs, there's a global lock that must be
4493 held by the current thread before it can safely access Python objects.
4494 Without the lock, even the simplest operations could cause problems in
4495 a multi-threaded program: for example, when two threads simultaneously
4496 increment the reference count of the same object, the reference count
4497 could end up being incremented only once instead of twice.
4499 Therefore, the rule exists that only the thread that has acquired the
4500 global interpreter lock may operate on Python objects or call Python/C
4501 API functions. In order to support multi-threaded Python programs,
4502 the interpreter regularly releases and reacquires the lock --- by
4503 default, every ten bytecode instructions (this can be changed with
4504 \withsubitem{(in module sys)
}{\ttindex{setcheckinterval()
}}
4505 \function{sys.setcheckinterval()
}). The lock is also released and
4506 reacquired around potentially blocking I/O operations like reading or
4507 writing a file, so that other threads can run while the thread that
4508 requests the I/O is waiting for the I/O operation to complete.
4510 The Python interpreter needs to keep some bookkeeping information
4511 separate per thread --- for this it uses a data structure called
4512 \ctype{PyThreadState
}\ttindex{PyThreadState
}. This is new in Python
4513 1.5; in earlier versions, such state was stored in global variables,
4514 and switching threads could cause problems. In particular, exception
4515 handling is now thread safe, when the application uses
4516 \withsubitem{(in module sys)
}{\ttindex{exc_info()
}}
4517 \function{sys.exc_info()
} to access the exception last raised in the
4520 There's one global variable left, however: the pointer to the current
4521 \ctype{PyThreadState
}\ttindex{PyThreadState
} structure. While most
4522 thread packages have a way to store ``per-thread global data,''
4523 Python's internal platform independent thread abstraction doesn't
4524 support this yet. Therefore, the current thread state must be
4525 manipulated explicitly.
4527 This is easy enough in most cases. Most code manipulating the global
4528 interpreter lock has the following simple structure:
4531 Save the thread state in a local variable.
4532 Release the interpreter lock.
4533 ...Do some blocking I/O operation...
4534 Reacquire the interpreter lock.
4535 Restore the thread state from the local variable.
4538 This is so common that a pair of macros exists to simplify it:
4541 Py_BEGIN_ALLOW_THREADS
4542 ...Do some blocking I/O operation...
4543 Py_END_ALLOW_THREADS
4546 The
\code{Py_BEGIN_ALLOW_THREADS
}\ttindex{Py_BEGIN_ALLOW_THREADS
} macro
4547 opens a new block and declares a hidden local variable; the
4548 \code{Py_END_ALLOW_THREADS
}\ttindex{Py_END_ALLOW_THREADS
} macro closes
4549 the block. Another advantage of using these two macros is that when
4550 Python is compiled without thread support, they are defined empty,
4551 thus saving the thread state and lock manipulations.
4553 When thread support is enabled, the block above expands to the
4557 PyThreadState *_save;
4559 _save = PyEval_SaveThread();
4560 ...Do some blocking I/O operation...
4561 PyEval_RestoreThread(_save);
4564 Using even lower level primitives, we can get roughly the same effect
4568 PyThreadState *_save;
4570 _save = PyThreadState_Swap(NULL);
4571 PyEval_ReleaseLock();
4572 ...Do some blocking I/O operation...
4573 PyEval_AcquireLock();
4574 PyThreadState_Swap(_save);
4577 There are some subtle differences; in particular,
4578 \cfunction{PyEval_RestoreThread()
}\ttindex{PyEval_RestoreThread()
} saves
4579 and restores the value of the global variable
4580 \cdata{errno
}\ttindex{errno
}, since the lock manipulation does not
4581 guarantee that
\cdata{errno
} is left alone. Also, when thread support
4583 \cfunction{PyEval_SaveThread()
}\ttindex{PyEval_SaveThread()
} and
4584 \cfunction{PyEval_RestoreThread()
} don't manipulate the lock; in this
4585 case,
\cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
} and
4586 \cfunction{PyEval_AcquireLock()
}\ttindex{PyEval_AcquireLock()
} are not
4587 available. This is done so that dynamically loaded extensions
4588 compiled with thread support enabled can be loaded by an interpreter
4589 that was compiled with disabled thread support.
4591 The global interpreter lock is used to protect the pointer to the
4592 current thread state. When releasing the lock and saving the thread
4593 state, the current thread state pointer must be retrieved before the
4594 lock is released (since another thread could immediately acquire the
4595 lock and store its own thread state in the global variable).
4596 Conversely, when acquiring the lock and restoring the thread state,
4597 the lock must be acquired before storing the thread state pointer.
4599 Why am I going on with so much detail about this? Because when
4600 threads are created from C, they don't have the global interpreter
4601 lock, nor is there a thread state data structure for them. Such
4602 threads must bootstrap themselves into existence, by first creating a
4603 thread state data structure, then acquiring the lock, and finally
4604 storing their thread state pointer, before they can start using the
4605 Python/C API. When they are done, they should reset the thread state
4606 pointer, release the lock, and finally free their thread state data
4609 When creating a thread data structure, you need to provide an
4610 interpreter state data structure. The interpreter state data
4611 structure hold global data that is shared by all threads in an
4612 interpreter, for example the module administration
4613 (
\code{sys.modules
}). Depending on your needs, you can either create
4614 a new interpreter state data structure, or share the interpreter state
4615 data structure used by the Python main thread (to access the latter,
4616 you must obtain the thread state and access its
\member{interp
} member;
4617 this must be done by a thread that is created by Python or by the main
4618 thread after Python is initialized).
4621 \begin{ctypedesc
}{PyInterpreterState
}
4622 This data structure represents the state shared by a number of
4623 cooperating threads. Threads belonging to the same interpreter
4624 share their module administration and a few other internal items.
4625 There are no public members in this structure.
4627 Threads belonging to different interpreters initially share nothing,
4628 except process state like available memory, open file descriptors and
4629 such. The global interpreter lock is also shared by all threads,
4630 regardless of to which interpreter they belong.
4633 \begin{ctypedesc
}{PyThreadState
}
4634 This data structure represents the state of a single thread. The only
4635 public data member is
\ctype{PyInterpreterState *
}\member{interp
},
4636 which points to this thread's interpreter state.
4639 \begin{cfuncdesc
}{void
}{PyEval_InitThreads
}{}
4640 Initialize and acquire the global interpreter lock. It should be
4641 called in the main thread before creating a second thread or engaging
4642 in any other thread operations such as
4643 \cfunction{PyEval_ReleaseLock()
}\ttindex{PyEval_ReleaseLock()
} or
4644 \code{PyEval_ReleaseThread(
\var{tstate
})
}\ttindex{PyEval_ReleaseThread()
}.
4645 It is not needed before calling
4646 \cfunction{PyEval_SaveThread()
}\ttindex{PyEval_SaveThread()
} or
4647 \cfunction{PyEval_RestoreThread()
}\ttindex{PyEval_RestoreThread()
}.
4649 This is a no-op when called for a second time. It is safe to call
4650 this function before calling
4651 \cfunction{Py_Initialize()
}\ttindex{Py_Initialize()
}.
4653 When only the main thread exists, no lock operations are needed. This
4654 is a common situation (most Python programs do not use threads), and
4655 the lock operations slow the interpreter down a bit. Therefore, the
4656 lock is not created initially. This situation is equivalent to having
4657 acquired the lock: when there is only a single thread, all object
4658 accesses are safe. Therefore, when this function initializes the
4659 lock, it also acquires it. Before the Python
4660 \module{thread
}\refbimodindex{thread
} module creates a new thread,
4661 knowing that either it has the lock or the lock hasn't been created
4662 yet, it calls
\cfunction{PyEval_InitThreads()
}. When this call
4663 returns, it is guaranteed that the lock has been created and that it
4666 It is
\strong{not
} safe to call this function when it is unknown which
4667 thread (if any) currently has the global interpreter lock.
4669 This function is not available when thread support is disabled at
4673 \begin{cfuncdesc
}{void
}{PyEval_AcquireLock
}{}
4674 Acquire the global interpreter lock. The lock must have been created
4675 earlier. If this thread already has the lock, a deadlock ensues.
4676 This function is not available when thread support is disabled at
4680 \begin{cfuncdesc
}{void
}{PyEval_ReleaseLock
}{}
4681 Release the global interpreter lock. The lock must have been created
4682 earlier. This function is not available when thread support is
4683 disabled at compile time.
4686 \begin{cfuncdesc
}{void
}{PyEval_AcquireThread
}{PyThreadState *tstate
}
4687 Acquire the global interpreter lock and then set the current thread
4688 state to
\var{tstate
}, which should not be
\NULL{}. The lock must
4689 have been created earlier. If this thread already has the lock,
4690 deadlock ensues. This function is not available when thread support
4691 is disabled at compile time.
4694 \begin{cfuncdesc
}{void
}{PyEval_ReleaseThread
}{PyThreadState *tstate
}
4695 Reset the current thread state to
\NULL{} and release the global
4696 interpreter lock. The lock must have been created earlier and must be
4697 held by the current thread. The
\var{tstate
} argument, which must not
4698 be
\NULL{}, is only used to check that it represents the current
4699 thread state --- if it isn't, a fatal error is reported. This
4700 function is not available when thread support is disabled at compile
4704 \begin{cfuncdesc
}{PyThreadState*
}{PyEval_SaveThread
}{}
4705 Release the interpreter lock (if it has been created and thread
4706 support is enabled) and reset the thread state to
\NULL{},
4707 returning the previous thread state (which is not
\NULL{}). If
4708 the lock has been created, the current thread must have acquired it.
4709 (This function is available even when thread support is disabled at
4713 \begin{cfuncdesc
}{void
}{PyEval_RestoreThread
}{PyThreadState *tstate
}
4714 Acquire the interpreter lock (if it has been created and thread
4715 support is enabled) and set the thread state to
\var{tstate
}, which
4716 must not be
\NULL{}. If the lock has been created, the current
4717 thread must not have acquired it, otherwise deadlock ensues. (This
4718 function is available even when thread support is disabled at compile
4722 The following macros are normally used without a trailing semicolon;
4723 look for example usage in the Python source distribution.
4725 \begin{csimplemacrodesc
}{Py_BEGIN_ALLOW_THREADS
}
4726 This macro expands to
4727 \samp{\
{ PyThreadState *_save; _save = PyEval_SaveThread();
}.
4728 Note that it contains an opening brace; it must be matched with a
4729 following
\code{Py_END_ALLOW_THREADS
} macro. See above for further
4730 discussion of this macro. It is a no-op when thread support is
4731 disabled at compile time.
4732 \end{csimplemacrodesc
}
4734 \begin{csimplemacrodesc
}{Py_END_ALLOW_THREADS
}
4735 This macro expands to
4736 \samp{PyEval_RestoreThread(_save); \
}}.
4737 Note that it contains a closing brace; it must be matched with an
4738 earlier
\code{Py_BEGIN_ALLOW_THREADS
} macro. See above for further
4739 discussion of this macro. It is a no-op when thread support is
4740 disabled at compile time.
4741 \end{csimplemacrodesc
}
4743 \begin{csimplemacrodesc
}{Py_BLOCK_THREADS
}
4744 This macro expands to
\samp{PyEval_RestoreThread(_save);
}: it
4745 is equivalent to
\code{Py_END_ALLOW_THREADS
} without the closing
4746 brace. It is a no-op when thread support is disabled at compile
4748 \end{csimplemacrodesc
}
4750 \begin{csimplemacrodesc
}{Py_UNBLOCK_THREADS
}
4751 This macro expands to
\samp{_save = PyEval_SaveThread();
}: it is
4752 equivalent to
\code{Py_BEGIN_ALLOW_THREADS
} without the opening brace
4753 and variable declaration. It is a no-op when thread support is
4754 disabled at compile time.
4755 \end{csimplemacrodesc
}
4757 All of the following functions are only available when thread support
4758 is enabled at compile time, and must be called only when the
4759 interpreter lock has been created.
4761 \begin{cfuncdesc
}{PyInterpreterState*
}{PyInterpreterState_New
}{}
4762 Create a new interpreter state object. The interpreter lock need not
4763 be held, but may be held if it is necessary to serialize calls to this
4767 \begin{cfuncdesc
}{void
}{PyInterpreterState_Clear
}{PyInterpreterState *interp
}
4768 Reset all information in an interpreter state object. The interpreter
4772 \begin{cfuncdesc
}{void
}{PyInterpreterState_Delete
}{PyInterpreterState *interp
}
4773 Destroy an interpreter state object. The interpreter lock need not be
4774 held. The interpreter state must have been reset with a previous
4775 call to
\cfunction{PyInterpreterState_Clear()
}.
4778 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_New
}{PyInterpreterState *interp
}
4779 Create a new thread state object belonging to the given interpreter
4780 object. The interpreter lock need not be held, but may be held if it
4781 is necessary to serialize calls to this function.
4784 \begin{cfuncdesc
}{void
}{PyThreadState_Clear
}{PyThreadState *tstate
}
4785 Reset all information in a thread state object. The interpreter lock
4789 \begin{cfuncdesc
}{void
}{PyThreadState_Delete
}{PyThreadState *tstate
}
4790 Destroy a thread state object. The interpreter lock need not be
4791 held. The thread state must have been reset with a previous
4792 call to
\cfunction{PyThreadState_Clear()
}.
4795 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_Get
}{}
4796 Return the current thread state. The interpreter lock must be held.
4797 When the current thread state is
\NULL{}, this issues a fatal
4798 error (so that the caller needn't check for
\NULL{}).
4801 \begin{cfuncdesc
}{PyThreadState*
}{PyThreadState_Swap
}{PyThreadState *tstate
}
4802 Swap the current thread state with the thread state given by the
4803 argument
\var{tstate
}, which may be
\NULL{}. The interpreter lock
4807 \begin{cfuncdesc
}{PyObject*
}{PyThreadState_GetDict
}{}
4808 Return a dictionary in which extensions can store thread-specific
4809 state information. Each extension should use a unique key to use to
4810 store state in the dictionary. If this function returns
\NULL, an
4811 exception has been raised and the caller should allow it to
4816 \section{Profiling and Tracing
\label{profiling
}}
4818 \sectionauthor{Fred L. Drake, Jr.
}{fdrake@acm.org
}
4820 The Python interpreter provides some low-level support for attaching
4821 profiling and execution tracing facilities. These are used for
4822 profiling, debugging, and coverage analysis tools.
4824 Starting with Python
2.2, the implementation of this facility was
4825 substantially revised, and an interface from C was added. This C
4826 interface allows the profiling or tracing code to avoid the overhead
4827 of calling through Python-level callable objects, making a direct C
4828 function call instead. The essential attributes of the facility have
4829 not changed; the interface allows trace functions to be installed
4830 per-thread, and the basic events reported to the trace function are
4831 the same as had been reported to the Python-level trace functions in
4834 \begin{ctypedesc
}[Py_tracefunc
]{int
(*Py_tracefunc)(PyObject *obj,
4835 PyFrameObject *frame, int what,
4837 The type of the trace function registered using
4838 \cfunction{PyEval_SetProfile()} and \cfunction{PyEval_SetTrace()}.
4839 The first parameter is the object passed to the registration
4843 \begin{cvardesc}{int}{PyTrace_CALL}
4844 The value of the \var{what} parameter to a \ctype{Py_tracefunc}
4845 function when a new function or method call is being reported.
4848 \begin{cvardesc}{int}{PyTrace_EXCEPT}
4851 \begin{cvardesc}{int}{PyTrace_LINE}
4852 The value passed as the \var{what} parameter to a trace function
4853 (but not a profiling function) when a line-number event is being
4857 \begin{cvardesc}{int}{PyTrace_RETURN}
4858 The value for the \var{what} parameter to \ctype{Py_tracefunc}
4859 functions when a call is returning without propogating an exception.
4862 \begin{cfuncdesc}{void}{PyEval_SetProfile}{Py_tracefunc func, PyObject *obj}
4863 Set the profiler function to \var{func}. The \var{obj} parameter is
4864 passed to the function as its first parameter, and may be any Python
4865 object, or \NULL. If the profile function needs to maintain state,
4866 using a different value for \var{obj} for each thread provides a
4867 convenient and thread-safe place to store it. The profile function
4868 is called for all monitored events except the line-number events.
4871 \begin{cfuncdesc}{void}{PyEval_SetTrace}{Py_tracefunc func, PyObject *obj}
4872 Set the the tracing function to \var{func}. This is similar to
4873 \cfunction{PyEval_SetProfile()}, except the tracing function does
4874 receive line-number events.
4878 \section{Advanced Debugger Support \label{advanced-debugging}}
4879 \sectionauthor{Fred L. Drake, Jr.}{fdrake@acm.org}
4881 These functions are only intended to be used by advanced debugging
4884 \begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_Head}{}
4885 Return the interpreter state object at the head of the list of all
4890 \begin{cfuncdesc}{PyInterpreterState*}{PyInterpreterState_Next}{PyInterpreterState *interp}
4891 Return the next interpreter state object after \var{interp} from the
4892 list of all such objects.
4896 \begin{cfuncdesc}{PyThreadState *}{PyInterpreterState_ThreadHead}{PyInterpreterState *interp}
4897 Return the a pointer to the first \ctype{PyThreadState} object in the
4898 list of threads associated with the interpreter \var{interp}.
4902 \begin{cfuncdesc}{PyThreadState*}{PyThreadState_Next}{PyThreadState *tstate}
4903 Return the next thread state object after \var{tstate} from the list
4904 of all such objects belonging to the same \ctype{PyInterpreterState}
4910 \chapter{Memory Management \label{memory}}
4911 \sectionauthor{Vladimir Marangozov}{Vladimir.Marangozov@inrialpes.fr}
4914 \section{Overview \label{memoryOverview}}
4916 Memory management in Python involves a private heap containing all
4917 Python objects and data structures. The management of this private
4918 heap is ensured internally by the \emph{Python memory manager}. The
4919 Python memory manager has different components which deal with various
4920 dynamic storage management aspects, like sharing, segmentation,
4921 preallocation or caching.
4923 At the lowest level, a raw memory allocator ensures that there is
4924 enough room in the private heap for storing all Python-related data
4925 by interacting with the memory manager of the operating system. On top
4926 of the raw memory allocator, several object-specific allocators
4927 operate on the same heap and implement distinct memory management
4928 policies adapted to the peculiarities of every object type. For
4929 example, integer objects are managed differently within the heap than
4930 strings, tuples or dictionaries because integers imply different
4931 storage requirements and speed/space tradeoffs. The Python memory
4932 manager thus delegates some of the work to the object-specific
4933 allocators, but ensures that the latter operate within the bounds of
4936 It is important to understand that the management of the Python heap
4937 is performed by the interpreter itself and that the user has no
4938 control on it, even if she regularly manipulates object pointers to
4939 memory blocks inside that heap. The allocation of heap space for
4940 Python objects and other internal buffers is performed on demand by
4941 the Python memory manager through the Python/C API functions listed in
4944 To avoid memory corruption, extension writers should never try to
4945 operate on Python objects with the functions exported by the C
4946 library: \cfunction{malloc()}\ttindex{malloc()},
4947 \cfunction{calloc()}\ttindex{calloc()},
4948 \cfunction{realloc()}\ttindex{realloc()} and
4949 \cfunction{free()}\ttindex{free()}. This will result in
4950 mixed calls between the C allocator and the Python memory manager
4951 with fatal consequences, because they implement different algorithms
4952 and operate on different heaps. However, one may safely allocate and
4953 release memory blocks with the C library allocator for individual
4954 purposes, as shown in the following example:
4958 char *buf = (char *) malloc(BUFSIZ); /* for I/O */
4961 return PyErr_NoMemory();
4962 ...Do some I/O operation involving buf...
4963 res = PyString_FromString(buf);
4964 free(buf); /* malloc'ed */
4968 In this example, the memory request for the I/O buffer is handled by
4969 the C library allocator. The Python memory manager is involved only
4970 in the allocation of the string object returned as a result.
4972 In most situations, however, it is recommended to allocate memory from
4973 the Python heap specifically because the latter is under control of
4974 the Python memory manager. For example, this is required when the
4975 interpreter is extended with new object types written in C. Another
4976 reason for using the Python heap is the desire to
\emph{inform
} the
4977 Python memory manager about the memory needs of the extension module.
4978 Even when the requested memory is used exclusively for internal,
4979 highly-specific purposes, delegating all memory requests to the Python
4980 memory manager causes the interpreter to have a more accurate image of
4981 its memory footprint as a whole. Consequently, under certain
4982 circumstances, the Python memory manager may or may not trigger
4983 appropriate actions, like garbage collection, memory compaction or
4984 other preventive procedures. Note that by using the C library
4985 allocator as shown in the previous example, the allocated memory for
4986 the I/O buffer escapes completely the Python memory manager.
4989 \section{Memory Interface
\label{memoryInterface
}}
4991 The following function sets, modeled after the ANSI C standard, are
4992 available for allocating and releasing memory from the Python heap:
4995 \begin{cfuncdesc
}{void*
}{PyMem_Malloc
}{size_t n
}
4996 Allocates
\var{n
} bytes and returns a pointer of type
\ctype{void*
} to
4997 the allocated memory, or
\NULL{} if the request fails. Requesting zero
4998 bytes returns a non-
\NULL{} pointer.
4999 The memory will not have been initialized in any way.
5002 \begin{cfuncdesc
}{void*
}{PyMem_Realloc
}{void *p, size_t n
}
5003 Resizes the memory block pointed to by
\var{p
} to
\var{n
} bytes. The
5004 contents will be unchanged to the minimum of the old and the new
5005 sizes. If
\var{p
} is
\NULL{}, the call is equivalent to
5006 \cfunction{PyMem_Malloc(
\var{n
})
}; if
\var{n
} is equal to zero, the
5007 memory block is resized but is not freed, and the returned pointer is
5008 non-
\NULL{}. Unless
\var{p
} is
\NULL{}, it must have been returned by
5009 a previous call to
\cfunction{PyMem_Malloc()
} or
5010 \cfunction{PyMem_Realloc()
}.
5013 \begin{cfuncdesc
}{void
}{PyMem_Free
}{void *p
}
5014 Frees the memory block pointed to by
\var{p
}, which must have been
5015 returned by a previous call to
\cfunction{PyMem_Malloc()
} or
5016 \cfunction{PyMem_Realloc()
}. Otherwise, or if
5017 \cfunction{PyMem_Free(p)
} has been called before, undefined behaviour
5018 occurs. If
\var{p
} is
\NULL{}, no operation is performed.
5021 The following type-oriented macros are provided for convenience. Note
5022 that
\var{TYPE
} refers to any C type.
5024 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyMem_New
}{TYPE, size_t n
}
5025 Same as
\cfunction{PyMem_Malloc()
}, but allocates
\code{(
\var{n
} *
5026 sizeof(
\var{TYPE
}))
} bytes of memory. Returns a pointer cast to
5027 \ctype{\var{TYPE
}*
}.
5028 The memory will not have been initialized in any way.
5031 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyMem_Resize
}{void *p, TYPE, size_t n
}
5032 Same as
\cfunction{PyMem_Realloc()
}, but the memory block is resized
5033 to
\code{(
\var{n
} * sizeof(
\var{TYPE
}))
} bytes. Returns a pointer
5034 cast to
\ctype{\var{TYPE
}*
}.
5037 \begin{cfuncdesc
}{void
}{PyMem_Del
}{void *p
}
5038 Same as
\cfunction{PyMem_Free()
}.
5041 In addition, the following macro sets are provided for calling the
5042 Python memory allocator directly, without involving the C API functions
5043 listed above. However, note that their use does not preserve binary
5044 compatibility accross Python versions and is therefore deprecated in
5047 \cfunction{PyMem_MALLOC()
},
\cfunction{PyMem_REALLOC()
},
\cfunction{PyMem_FREE()
}.
5049 \cfunction{PyMem_NEW()
},
\cfunction{PyMem_RESIZE()
},
\cfunction{PyMem_DEL()
}.
5052 \section{Examples
\label{memoryExamples
}}
5054 Here is the example from section
\ref{memoryOverview
}, rewritten so
5055 that the I/O buffer is allocated from the Python heap by using the
5060 char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */
5063 return PyErr_NoMemory();
5064 /* ...Do some I/O operation involving buf... */
5065 res = PyString_FromString(buf);
5066 PyMem_Free(buf); /* allocated with PyMem_Malloc */
5070 The same code using the type-oriented function set:
5074 char *buf = PyMem_New(char, BUFSIZ); /* for I/O */
5077 return PyErr_NoMemory();
5078 /* ...Do some I/O operation involving buf... */
5079 res = PyString_FromString(buf);
5080 PyMem_Del(buf); /* allocated with PyMem_New */
5084 Note that in the two examples above, the buffer is always
5085 manipulated via functions belonging to the same set. Indeed, it
5086 is required to use the same memory API family for a given
5087 memory block, so that the risk of mixing different allocators is
5088 reduced to a minimum. The following code sequence contains two errors,
5089 one of which is labeled as
\emph{fatal
} because it mixes two different
5090 allocators operating on different heaps.
5093 char *buf1 = PyMem_New(char, BUFSIZ);
5094 char *buf2 = (char *) malloc(BUFSIZ);
5095 char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
5097 PyMem_Del(buf3); /* Wrong -- should be PyMem_Free() */
5098 free(buf2); /* Right -- allocated via malloc() */
5099 free(buf1); /* Fatal -- should be PyMem_Del() */
5102 In addition to the functions aimed at handling raw memory blocks from
5103 the Python heap, objects in Python are allocated and released with
5104 \cfunction{PyObject_New()
},
\cfunction{PyObject_NewVar()
} and
5105 \cfunction{PyObject_Del()
}, or with their corresponding macros
5106 \cfunction{PyObject_NEW()
},
\cfunction{PyObject_NEW_VAR()
} and
5107 \cfunction{PyObject_DEL()
}.
5109 These will be explained in the next chapter on defining and
5110 implementing new object types in C.
5113 \chapter{Defining New Object Types
\label{newTypes
}}
5116 \section{Allocating Objects on the Heap
5117 \label{allocating-objects
}}
5119 \begin{cfuncdesc
}{PyObject*
}{_PyObject_New
}{PyTypeObject *type
}
5122 \begin{cfuncdesc
}{PyVarObject*
}{_PyObject_NewVar
}{PyTypeObject *type, int size
}
5125 \begin{cfuncdesc
}{void
}{_PyObject_Del
}{PyObject *op
}
5128 \begin{cfuncdesc
}{PyObject*
}{PyObject_Init
}{PyObject *op,
5130 Initialize a newly-allocated object
\var{op
} with its type and
5131 initial reference. Returns the initialized object. If
\var{type
}
5132 indicates that the object participates in the cyclic garbage
5133 detector, it it added to the detector's set of observed objects.
5134 Other fields of the object are not affected.
5137 \begin{cfuncdesc
}{PyVarObject*
}{PyObject_InitVar
}{PyVarObject *op,
5138 PyTypeObject *type, int size
}
5139 This does everything
\cfunction{PyObject_Init()
} does, and also
5140 initializes the length information for a variable-size object.
5143 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_New
}{TYPE, PyTypeObject *type
}
5144 Allocate a new Python object using the C structure type
\var{TYPE
}
5145 and the Python type object
\var{type
}. Fields not defined by the
5146 Python object header are not initialized; the object's reference
5147 count will be one. The size of the memory
5148 allocation is determined from the
\member{tp_basicsize
} field of the
5152 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NewVar
}{TYPE, PyTypeObject *type,
5154 Allocate a new Python object using the C structure type
\var{TYPE
}
5155 and the Python type object
\var{type
}. Fields not defined by the
5156 Python object header are not initialized. The allocated memory
5157 allows for the
\var{TYPE
} structure plus
\var{size
} fields of the
5158 size given by the
\member{tp_itemsize
} field of
\var{type
}. This is
5159 useful for implementing objects like tuples, which are able to
5160 determine their size at construction time. Embedding the array of
5161 fields into the same allocation decreases the number of allocations,
5162 improving the memory management efficiency.
5165 \begin{cfuncdesc
}{void
}{PyObject_Del
}{PyObject *op
}
5166 Releases memory allocated to an object using
5167 \cfunction{PyObject_New()
} or
\cfunction{PyObject_NewVar()
}. This
5168 is normally called from the
\member{tp_dealloc
} handler specified in
5169 the object's type. The fields of the object should not be accessed
5170 after this call as the memory is no longer a valid Python object.
5173 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NEW
}{TYPE, PyTypeObject *type
}
5174 Macro version of
\cfunction{PyObject_New()
}, to gain performance at
5175 the expense of safety. This does not check
\var{type
} for a
\NULL{}
5179 \begin{cfuncdesc
}{\var{TYPE
}*
}{PyObject_NEW_VAR
}{TYPE, PyTypeObject *type,
5181 Macro version of
\cfunction{PyObject_NewVar()
}, to gain performance
5182 at the expense of safety. This does not check
\var{type
} for a
5186 \begin{cfuncdesc
}{void
}{PyObject_DEL
}{PyObject *op
}
5187 Macro version of
\cfunction{PyObject_Del()
}.
5190 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule
}{char *name,
5191 PyMethodDef *methods
}
5192 Create a new module object based on a name and table of functions,
5193 returning the new module object.
5196 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule3
}{char *name,
5197 PyMethodDef *methods,
5199 Create a new module object based on a name and table of functions,
5200 returning the new module object. If
\var{doc
} is non-
\NULL, it will
5201 be used to define the docstring for the module.
5204 \begin{cfuncdesc
}{PyObject*
}{Py_InitModule4
}{char *name,
5205 PyMethodDef *methods,
5206 char *doc, PyObject *self,
5208 Create a new module object based on a name and table of functions,
5209 returning the new module object. If
\var{doc
} is non-
\NULL, it will
5210 be used to define the docstring for the module. If
\var{self
} is
5211 non-
\NULL, it will passed to the functions of the module as their
5212 (otherwise
\NULL) first parameter. (This was added as an
5213 experimental feature, and there are no known uses in the current
5214 version of Python.) For
\var{apiver
}, the only value which should
5215 be passed is defined by the constant
\constant{PYTHON_API_VERSION
}.
5217 \strong{Note:
} Most uses of this function should probably be using
5218 the
\cfunction{Py_InitModule3()
} instead; only use this if you are
5224 \begin{cvardesc
}{PyObject
}{_Py_NoneStruct
}
5225 Object which is visible in Python as
\code{None
}. This should only
5226 be accessed using the
\code{Py_None
} macro, which evaluates to a
5227 pointer to this object.
5231 \section{Common Object Structures
\label{common-structs
}}
5233 PyObject, PyVarObject
5235 PyObject_HEAD, PyObject_HEAD_INIT, PyObject_VAR_HEAD
5238 unaryfunc, binaryfunc, ternaryfunc, inquiry, coercion, intargfunc,
5239 intintargfunc, intobjargproc, intintobjargproc, objobjargproc,
5240 destructor, printfunc, getattrfunc, getattrofunc, setattrfunc,
5241 setattrofunc, cmpfunc, reprfunc, hashfunc
5243 \begin{ctypedesc
}{PyCFunction
}
5244 Type of the functions used to implement most Python callables in C.
5247 \begin{ctypedesc
}{PyMethodDef
}
5248 Structure used to describe a method of an extension type. This
5249 structure has four fields:
5251 \begin{tableiii
}{l|l|l
}{member
}{Field
}{C Type
}{Meaning
}
5252 \lineiii{ml_name
}{char *
}{name of the method
}
5253 \lineiii{ml_meth
}{PyCFunction
}{pointer to the C implementation
}
5254 \lineiii{ml_flags
}{int
}{flag bits indicating how the call should be
5256 \lineiii{ml_doc
}{char *
}{points to the contents of the docstring
}
5260 \begin{cfuncdesc
}{PyObject*
}{Py_FindMethod
}{PyMethodDef
[] table,
5261 PyObject *ob, char *name
}
5262 Return a bound method object for an extension type implemented in C.
5263 This function also handles the special attribute
\member{__methods__
},
5264 returning a list of all the method names defined in
\var{table
}.
5268 \section{Mapping Object Structures
\label{mapping-structs
}}
5270 \begin{ctypedesc
}{PyMappingMethods
}
5271 Structure used to hold pointers to the functions used to implement the
5272 mapping protocol for an extension type.
5276 \section{Number Object Structures
\label{number-structs
}}
5278 \begin{ctypedesc
}{PyNumberMethods
}
5279 Structure used to hold pointers to the functions an extension type
5280 uses to implement the number protocol.
5284 \section{Sequence Object Structures
\label{sequence-structs
}}
5286 \begin{ctypedesc
}{PySequenceMethods
}
5287 Structure used to hold pointers to the functions which an object uses
5288 to implement the sequence protocol.
5292 \section{Buffer Object Structures
\label{buffer-structs
}}
5293 \sectionauthor{Greg J. Stein
}{greg@lyra.org
}
5295 The buffer interface exports a model where an object can expose its
5296 internal data as a set of chunks of data, where each chunk is
5297 specified as a pointer/length pair. These chunks are called
5298 \dfn{segments
} and are presumed to be non-contiguous in memory.
5300 If an object does not export the buffer interface, then its
5301 \member{tp_as_buffer
} member in the
\ctype{PyTypeObject
} structure
5302 should be
\NULL{}. Otherwise, the
\member{tp_as_buffer
} will point to
5303 a
\ctype{PyBufferProcs
} structure.
5305 \strong{Note:
} It is very important that your
5306 \ctype{PyTypeObject
} structure uses
\constant{Py_TPFLAGS_DEFAULT
} for
5307 the value of the
\member{tp_flags
} member rather than
\code{0}. This
5308 tells the Python runtime that your
\ctype{PyBufferProcs
} structure
5309 contains the
\member{bf_getcharbuffer
} slot. Older versions of Python
5310 did not have this member, so a new Python interpreter using an old
5311 extension needs to be able to test for its presence before using it.
5313 \begin{ctypedesc
}{PyBufferProcs
}
5314 Structure used to hold the function pointers which define an
5315 implementation of the buffer protocol.
5317 The first slot is
\member{bf_getreadbuffer
}, of type
5318 \ctype{getreadbufferproc
}. If this slot is
\NULL{}, then the object
5319 does not support reading from the internal data. This is
5320 non-sensical, so implementors should fill this in, but callers should
5321 test that the slot contains a non-
\NULL{} value.
5323 The next slot is
\member{bf_getwritebuffer
} having type
5324 \ctype{getwritebufferproc
}. This slot may be
\NULL{} if the object
5325 does not allow writing into its returned buffers.
5327 The third slot is
\member{bf_getsegcount
}, with type
5328 \ctype{getsegcountproc
}. This slot must not be
\NULL{} and is used to
5329 inform the caller how many segments the object contains. Simple
5330 objects such as
\ctype{PyString_Type
} and
5331 \ctype{PyBuffer_Type
} objects contain a single segment.
5333 The last slot is
\member{bf_getcharbuffer
}, of type
5334 \ctype{getcharbufferproc
}. This slot will only be present if the
5335 \constant{Py_TPFLAGS_HAVE_GETCHARBUFFER
} flag is present in the
5336 \member{tp_flags
} field of the object's
\ctype{PyTypeObject
}. Before using
5337 this slot, the caller should test whether it is present by using the
5338 \cfunction{PyType_HasFeature()
}\ttindex{PyType_HasFeature()
} function.
5339 If present, it may be
\NULL, indicating that the object's contents
5340 cannot be used as
\emph{8-bit characters
}.
5341 The slot function may also raise an error if the object's contents
5342 cannot be interpreted as
8-bit characters. For example, if the object
5343 is an array which is configured to hold floating point values, an
5344 exception may be raised if a caller attempts to use
5345 \member{bf_getcharbuffer
} to fetch a sequence of
8-bit characters.
5346 This notion of exporting the internal buffers as ``text'' is used to
5347 distinguish between objects that are binary in nature, and those which
5348 have character-based content.
5350 \strong{Note:
} The current policy seems to state that these characters
5351 may be multi-byte characters. This implies that a buffer size of
5352 \var{N
} does not mean there are
\var{N
} characters present.
5355 \begin{datadesc
}{Py_TPFLAGS_HAVE_GETCHARBUFFER
}
5356 Flag bit set in the type structure to indicate that the
5357 \member{bf_getcharbuffer
} slot is known. This being set does not
5358 indicate that the object supports the buffer interface or that the
5359 \member{bf_getcharbuffer
} slot is non-
\NULL.
5362 \begin{ctypedesc
}[getreadbufferproc
]{int
(*getreadbufferproc)
5363 (PyObject *self, int segment, void **ptrptr)}
5364 Return a pointer to a readable segment of the buffer. This function
5365 is allowed to raise an exception, in which case it must return
5366 \code{-1}. The \var{segment} which is passed must be zero or
5367 positive, and strictly less than the number of segments returned by
5368 the \member{bf_getsegcount} slot function. On success, it returns the
5369 length of the buffer memory, and sets \code{*\var{ptrptr}} to a
5370 pointer to that memory.
5373 \begin{ctypedesc}[getwritebufferproc]{int (*getwritebufferproc)
5374 (PyObject *self, int segment, void **ptrptr)}
5375 Return a pointer to a writable memory buffer in \code{*\var{ptrptr}},
5376 and the length of that segment as the function return value.
5377 The memory buffer must correspond to buffer segment \var{segment}.
5378 Must return \code{-1} and set an exception on error.
5379 \exception{TypeError} should be raised if the object only supports
5380 read-only buffers, and \exception{SystemError} should be raised when
5381 \var{segment} specifies a segment that doesn't exist.
5382 % Why doesn't it raise ValueError for this one?
5383 % GJS: because you shouldn't be calling it with an invalid
5384 % segment. That indicates a blatant programming error in the C
5388 \begin{ctypedesc}[getsegcountproc]{int (*getsegcountproc)
5389 (PyObject *self, int *lenp)}
5390 Return the number of memory segments which comprise the buffer. If
5391 \var{lenp} is not \NULL, the implementation must report the sum of the
5392 sizes (in bytes) of all segments in \code{*\var{lenp}}.
5393 The function cannot fail.
5396 \begin{ctypedesc}[getcharbufferproc]{int (*getcharbufferproc)
5397 (PyObject *self, int segment, const char **ptrptr)}
5401 \section{Supporting the Iterator Protocol
5402 \label{supporting-iteration}}
5405 \section{Supporting Cyclic Garbarge Collection
5406 \label{supporting-cycle-detection}}
5408 Python's support for detecting and collecting garbage which involves
5409 circular references requires support from object types which are
5410 ``containers'' for other objects which may also be containers. Types
5411 which do not store references to other objects, or which only store
5412 references to atomic types (such as numbers or strings), do not need
5413 to provide any explicit support for garbage collection.
5415 To create a container type, the \member{tp_flags} field of the type
5416 object must include the \constant{Py_TPFLAGS_GC} and provide an
5417 implementation of the \member{tp_traverse} handler. The computed
5418 value of the \member{tp_basicsize} field must include
5419 \constant{PyGC_HEAD_SIZE} as well. If instances of the type are
5420 mutable, a \member{tp_clear} implementation must also be provided.
5422 \begin{datadesc}{Py_TPFLAGS_GC}
5423 Objects with a type with this flag set must conform with the rules
5424 documented here. For convenience these objects will be referred to
5425 as container objects.
5428 \begin{datadesc}{PyGC_HEAD_SIZE}
5429 Extra memory needed for the garbage collector. Container objects
5430 must include this in the calculation of their tp_basicsize. If the
5431 collector is disabled at compile time then this is \code{0}.
5434 Constructors for container types must conform to two rules:
5437 \item The memory for the object must be allocated using
5438 \cfunction{PyObject_New()} or \cfunction{PyObject_VarNew()}.
5440 \item Once all the fields which may contain references to other
5441 containers are initialized, it must call
5442 \cfunction{PyObject_GC_Init()}.
5445 \begin{cfuncdesc}{void}{PyObject_GC_Init}{PyObject *op}
5446 Adds the object \var{op} to the set of container objects tracked by
5447 the collector. The collector can run at unexpected times so objects
5448 must be valid while being tracked. This should be called once all
5449 the fields followed by the \member{tp_traverse} handler become valid,
5450 usually near the end of the constructor.
5453 Similarly, the deallocator for the object must conform to a similar
5457 \item Before fields which refer to other containers are invalidated,
5458 \cfunction{PyObject_GC_Fini()} must be called.
5460 \item The object's memory must be deallocated using
5461 \cfunction{PyObject_Del()}.
5464 \begin{cfuncdesc}{void}{PyObject_GC_Fini}{PyObject *op}
5465 Remove the object \var{op} from the set of container objects tracked
5466 by the collector. Note that \cfunction{PyObject_GC_Init()} can be
5467 called again on this object to add it back to the set of tracked
5468 objects. The deallocator (\member{tp_dealloc} handler) should call
5469 this for the object before any of the fields used by the
5470 \member{tp_traverse} handler become invalid.
5472 \strong{Note:} Any container which may be referenced from another
5473 object reachable by the collector must itself be tracked by the
5474 collector, so it is generally not safe to call this function
5475 anywhere but in the object's deallocator.
5478 The \member{tp_traverse} handler accepts a function parameter of this
5481 \begin{ctypedesc}[visitproc]{int (*visitproc)(PyObject *object, void *arg)}
5482 Type of the visitor function passed to the \member{tp_traverse}
5483 handler. The function should be called with an object to traverse
5484 as \var{object} and the third parameter to the \member{tp_traverse}
5485 handler as \var{arg}.
5488 The \member{tp_traverse} handler must have the following type:
5490 \begin{ctypedesc}[traverseproc]{int (*traverseproc)(PyObject *self,
5491 visitproc visit, void *arg)}
5492 Traversal function for a container object. Implementations must
5493 call the \var{visit} function for each object directly contained by
5494 \var{self}, with the parameters to \var{visit} being the contained
5495 object and the \var{arg} value passed to the handler. If
5496 \var{visit} returns a non-zero value then an error has occurred and
5497 that value should be returned immediately.
5500 The \member{tp_clear} handler must be of the \ctype{inquiry} type, or
5501 \NULL{} if the object is immutable.
5503 \begin{ctypedesc}[inquiry]{int (*inquiry)(PyObject *self)}
5504 Drop references that may have created reference cycles. Immutable
5505 objects do not have to define this method since they can never
5506 directly create reference cycles. Note that the object must still
5507 be valid after calling this method (don't just call
5508 \cfunction{Py_DECREF()} on a reference). The collector will call
5509 this method if it detects that this object is involved in a
5514 \subsection{Example Cycle Collector Support
5515 \label{example-cycle-support}}
5517 This example shows only enough of the implementation of an extension
5518 type to show how the garbage collector support needs to be added. It
5519 shows the definition of the object structure, the
5520 \member{tp_traverse}, \member{tp_clear} and \member{tp_dealloc}
5521 implementations, the type structure, and a constructor --- the module
5522 initialization needed to export the constructor to Python is not shown
5523 as there are no special considerations there for the collector. To
5524 make this interesting, assume that the module exposes ways for the
5525 \member{container} field of the object to be modified. Note that
5526 since no checks are made on the type of the object used to initialize
5527 \member{container}, we have to assume that it may be a container.
5534 PyObject *container;
5538 my_traverse(MyObject *self, visitproc visit, void *arg)
5540 if (self->container != NULL)
5541 return visit(self->container, arg);
5547 my_clear(MyObject *self)
5549 Py_XDECREF(self->container);
5550 self->container = NULL;
5556 my_dealloc(MyObject *self)
5558 PyObject_GC_Fini((PyObject *) self);
5559 Py_XDECREF(self->container);
5565 statichere PyTypeObject
5567 PyObject_HEAD_INIT(NULL)
5570 sizeof(MyObject) + PyGC_HEAD_SIZE,
5572 (destructor)my_dealloc, /* tp_dealloc */
5578 0, /* tp_as_number */
5579 0, /* tp_as_sequence */
5580 0, /* tp_as_mapping */
5584 0, /* tp_getattro */
5585 0, /* tp_setattro */
5586 0, /* tp_as_buffer */
5587 Py_TPFLAGS_DEFAULT | Py_TPFLAGS_GC,
5589 (traverseproc)my_traverse, /* tp_traverse */
5590 (inquiry)my_clear, /* tp_clear */
5591 0, /* tp_richcompare */
5592 0, /* tp_weaklistoffset */
5595 /* This constructor should be made accessible from Python. */
5597 new_object(PyObject *unused, PyObject *args)
5599 PyObject *container = NULL;
5600 MyObject *result = NULL;
5602 if (PyArg_ParseTuple(args, "|O:new_object", &container))
{
5603 result = PyObject_New(MyObject, &MyObject_Type);
5604 if (result != NULL)
{
5605 result->container = container;
5609 return (PyObject *) result;
5614 % \chapter{Debugging \label{debugging}}
5616 % XXX Explain Py_DEBUG, Py_TRACE_REFS, Py_REF_DEBUG.
5620 \chapter{Reporting Bugs
}
5621 \input{reportingbugs
}
5623 \chapter{History and License
}
5626 \input{api.ind
} % Index -- must be last