Move the 3k reST doc tree in place.

11 files changed, 10116 insertions, 0 deletions

diff --git a/Doc/c-api/abstract.rst b/Doc/c-api/abstract.rst
new file mode 100644
index 0000000..1a1ff13
--- /dev/null
+++ b/Doc/c-api/abstract.rst
@@ -0,0 +1,997 @@
+.. highlightlang:: c
+
+
+.. _abstract:
+
+**********************
+Abstract Objects Layer
+**********************
+
+The functions in this chapter interact with Python objects regardless of their
+type, or with wide classes of object types (e.g. all numerical types, or all
+sequence types).  When used on object types for which they do not apply, they
+will raise a Python exception.
+
+It is not possible to use these functions on objects that are not properly
+initialized, such as a list object that has been created by :cfunc:`PyList_New`,
+but whose items have not been set to some non-\ ``NULL`` value yet.
+
+
+.. _object:
+
+Object Protocol
+===============
+
+
+.. cfunction:: int PyObject_Print(PyObject *o, FILE *fp, int flags)
+
+   Print an object *o*, on file *fp*.  Returns ``-1`` on error.  The flags argument
+   is used to enable certain printing options.  The only option currently supported
+   is :const:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
+   instead of the :func:`repr`.
+
+
+.. cfunction:: int PyObject_HasAttrString(PyObject *o, const char *attr_name)
+
+   Returns ``1`` if *o* has the attribute *attr_name*, and ``0`` otherwise.  This
+   is equivalent to the Python expression ``hasattr(o, attr_name)``.  This function
+   always succeeds.
+
+
+.. cfunction:: PyObject* PyObject_GetAttrString(PyObject *o, const char *attr_name)
+
+   Retrieve an attribute named *attr_name* from object *o*. Returns the attribute
+   value on success, or *NULL* on failure. This is the equivalent of the Python
+   expression ``o.attr_name``.
+
+
+.. cfunction:: int PyObject_HasAttr(PyObject *o, PyObject *attr_name)
+
+   Returns ``1`` if *o* has the attribute *attr_name*, and ``0`` otherwise.  This
+   is equivalent to the Python expression ``hasattr(o, attr_name)``.  This function
+   always succeeds.
+
+
+.. cfunction:: PyObject* PyObject_GetAttr(PyObject *o, PyObject *attr_name)
+
+   Retrieve an attribute named *attr_name* from object *o*. Returns the attribute
+   value on success, or *NULL* on failure.  This is the equivalent of the Python
+   expression ``o.attr_name``.
+
+
+.. cfunction:: int PyObject_SetAttrString(PyObject *o, const char *attr_name, PyObject *v)
+
+   Set the value of the attribute named *attr_name*, for object *o*, to the value
+   *v*. Returns ``-1`` on failure.  This is the equivalent of the Python statement
+   ``o.attr_name = v``.
+
+
+.. cfunction:: int PyObject_SetAttr(PyObject *o, PyObject *attr_name, PyObject *v)
+
+   Set the value of the attribute named *attr_name*, for object *o*, to the value
+   *v*. Returns ``-1`` on failure.  This is the equivalent of the Python statement
+   ``o.attr_name = v``.
+
+
+.. cfunction:: int PyObject_DelAttrString(PyObject *o, const char *attr_name)
+
+   Delete attribute named *attr_name*, for object *o*. Returns ``-1`` on failure.
+   This is the equivalent of the Python statement: ``del o.attr_name``.
+
+
+.. cfunction:: int PyObject_DelAttr(PyObject *o, PyObject *attr_name)
+
+   Delete attribute named *attr_name*, for object *o*. Returns ``-1`` on failure.
+   This is the equivalent of the Python statement ``del o.attr_name``.
+
+
+.. cfunction:: PyObject* PyObject_RichCompare(PyObject *o1, PyObject *o2, int opid)
+
+   Compare the values of *o1* and *o2* using the operation specified by *opid*,
+   which must be one of :const:`Py_LT`, :const:`Py_LE`, :const:`Py_EQ`,
+   :const:`Py_NE`, :const:`Py_GT`, or :const:`Py_GE`, corresponding to ``<``,
+   ``<=``, ``==``, ``!=``, ``>``, or ``>=`` respectively. This is the equivalent of
+   the Python expression ``o1 op o2``, where ``op`` is the operator corresponding
+   to *opid*. Returns the value of the comparison on success, or *NULL* on failure.
+
+
+.. cfunction:: int PyObject_RichCompareBool(PyObject *o1, PyObject *o2, int opid)
+
+   Compare the values of *o1* and *o2* using the operation specified by *opid*,
+   which must be one of :const:`Py_LT`, :const:`Py_LE`, :const:`Py_EQ`,
+   :const:`Py_NE`, :const:`Py_GT`, or :const:`Py_GE`, corresponding to ``<``,
+   ``<=``, ``==``, ``!=``, ``>``, or ``>=`` respectively. Returns ``-1`` on error,
+   ``0`` if the result is false, ``1`` otherwise. This is the equivalent of the
+   Python expression ``o1 op o2``, where ``op`` is the operator corresponding to
+   *opid*.
+
+
+.. cfunction:: int PyObject_Cmp(PyObject *o1, PyObject *o2, int *result)
+
+   .. index:: builtin: cmp
+
+   Compare the values of *o1* and *o2* using a routine provided by *o1*, if one
+   exists, otherwise with a routine provided by *o2*.  The result of the comparison
+   is returned in *result*.  Returns ``-1`` on failure.  This is the equivalent of
+   the Python statement ``result = cmp(o1, o2)``.
+
+
+.. cfunction:: int PyObject_Compare(PyObject *o1, PyObject *o2)
+
+   .. index:: builtin: cmp
+
+   Compare the values of *o1* and *o2* using a routine provided by *o1*, if one
+   exists, otherwise with a routine provided by *o2*.  Returns the result of the
+   comparison on success.  On error, the value returned is undefined; use
+   :cfunc:`PyErr_Occurred` to detect an error.  This is equivalent to the Python
+   expression ``cmp(o1, o2)``.
+
+
+.. cfunction:: PyObject* PyObject_Repr(PyObject *o)
+
+   .. index:: builtin: repr
+
+   Compute a string representation of object *o*.  Returns the string
+   representation on success, *NULL* on failure.  This is the equivalent of the
+   Python expression ``repr(o)``.  Called by the :func:`repr` built-in function and
+   by reverse quotes.
+
+
+.. cfunction:: PyObject* PyObject_Str(PyObject *o)
+
+   .. index:: builtin: str
+
+   Compute a string representation of object *o*.  Returns the string
+   representation on success, *NULL* on failure.  This is the equivalent of the
+   Python expression ``str(o)``.  Called by the :func:`str` built-in function and
+   by the :keyword:`print` statement.
+
+
+.. cfunction:: PyObject* PyObject_Unicode(PyObject *o)
+
+   .. index:: builtin: unicode
+
+   Compute a Unicode string representation of object *o*.  Returns the Unicode
+   string representation on success, *NULL* on failure. This is the equivalent of
+   the Python expression ``unicode(o)``.  Called by the :func:`unicode` built-in
+   function.
+
+
+.. cfunction:: int PyObject_IsInstance(PyObject *inst, PyObject *cls)
+
+   Returns ``1`` if *inst* is an instance of the class *cls* or a subclass of
+   *cls*, or ``0`` if not.  On error, returns ``-1`` and sets an exception.  If
+   *cls* is a type object rather than a class object, :cfunc:`PyObject_IsInstance`
+   returns ``1`` if *inst* is of type *cls*.  If *cls* is a tuple, the check will
+   be done against every entry in *cls*. The result will be ``1`` when at least one
+   of the checks returns ``1``, otherwise it will be ``0``. If *inst* is not a
+   class instance and *cls* is neither a type object, nor a class object, nor a
+   tuple, *inst* must have a :attr:`__class__` attribute --- the class relationship
+   of the value of that attribute with *cls* will be used to determine the result
+   of this function.
+
+   .. versionadded:: 2.1
+
+   .. versionchanged:: 2.2
+      Support for a tuple as the second argument added.
+
+Subclass determination is done in a fairly straightforward way, but includes a
+wrinkle that implementors of extensions to the class system may want to be aware
+of.  If :class:`A` and :class:`B` are class objects, :class:`B` is a subclass of
+:class:`A` if it inherits from :class:`A` either directly or indirectly.  If
+either is not a class object, a more general mechanism is used to determine the
+class relationship of the two objects.  When testing if *B* is a subclass of
+*A*, if *A* is *B*, :cfunc:`PyObject_IsSubclass` returns true.  If *A* and *B*
+are different objects, *B*'s :attr:`__bases__` attribute is searched in a
+depth-first fashion for *A* --- the presence of the :attr:`__bases__` attribute
+is considered sufficient for this determination.
+
+
+.. cfunction:: int PyObject_IsSubclass(PyObject *derived, PyObject *cls)
+
+   Returns ``1`` if the class *derived* is identical to or derived from the class
+   *cls*, otherwise returns ``0``.  In case of an error, returns ``-1``. If *cls*
+   is a tuple, the check will be done against every entry in *cls*. The result will
+   be ``1`` when at least one of the checks returns ``1``, otherwise it will be
+   ``0``. If either *derived* or *cls* is not an actual class object (or tuple),
+   this function uses the generic algorithm described above.
+
+   .. versionadded:: 2.1
+
+   .. versionchanged:: 2.3
+      Older versions of Python did not support a tuple as the second argument.
+
+
+.. cfunction:: int PyCallable_Check(PyObject *o)
+
+   Determine if the object *o* is callable.  Return ``1`` if the object is callable
+   and ``0`` otherwise.  This function always succeeds.
+
+
+.. cfunction:: PyObject* PyObject_Call(PyObject *callable_object, PyObject *args, PyObject *kw)
+
+   Call a callable Python object *callable_object*, with arguments given by the
+   tuple *args*, and named arguments given by the dictionary *kw*. If no named
+   arguments are needed, *kw* may be *NULL*. *args* must not be *NULL*, use an
+   empty tuple if no arguments are needed. Returns the result of the call on
+   success, or *NULL* on failure.  This is the equivalent of the Python expression
+   ``callable_object(*args, **kw)``.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyObject_CallObject(PyObject *callable_object, PyObject *args)
+
+   Call a callable Python object *callable_object*, with arguments given by the
+   tuple *args*.  If no arguments are needed, then *args* may be *NULL*.  Returns
+   the result of the call on success, or *NULL* on failure.  This is the equivalent
+   of the Python expression ``callable_object(*args)``.
+
+
+.. cfunction:: PyObject* PyObject_CallFunction(PyObject *callable, char *format, ...)
+
+   Call a callable Python object *callable*, with a variable number of C arguments.
+   The C arguments are described using a :cfunc:`Py_BuildValue` style format
+   string.  The format may be *NULL*, indicating that no arguments are provided.
+   Returns the result of the call on success, or *NULL* on failure.  This is the
+   equivalent of the Python expression ``callable(*args)``. Note that if you only
+   pass :ctype:`PyObject \*` args, :cfunc:`PyObject_CallFunctionObjArgs` is a
+   faster alternative.
+
+
+.. cfunction:: PyObject* PyObject_CallMethod(PyObject *o, char *method, char *format, ...)
+
+   Call the method named *method* of object *o* with a variable number of C
+   arguments.  The C arguments are described by a :cfunc:`Py_BuildValue` format
+   string that should  produce a tuple.  The format may be *NULL*, indicating that
+   no arguments are provided. Returns the result of the call on success, or *NULL*
+   on failure.  This is the equivalent of the Python expression ``o.method(args)``.
+   Note that if you only pass :ctype:`PyObject \*` args,
+   :cfunc:`PyObject_CallMethodObjArgs` is a faster alternative.
+
+
+.. cfunction:: PyObject* PyObject_CallFunctionObjArgs(PyObject *callable, ..., NULL)
+
+   Call a callable Python object *callable*, with a variable number of
+   :ctype:`PyObject\*` arguments.  The arguments are provided as a variable number
+   of parameters followed by *NULL*. Returns the result of the call on success, or
+   *NULL* on failure.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyObject_CallMethodObjArgs(PyObject *o, PyObject *name, ..., NULL)
+
+   Calls a method of the object *o*, where the name of the method is given as a
+   Python string object in *name*.  It is called with a variable number of
+   :ctype:`PyObject\*` arguments.  The arguments are provided as a variable number
+   of parameters followed by *NULL*. Returns the result of the call on success, or
+   *NULL* on failure.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: long PyObject_Hash(PyObject *o)
+
+   .. index:: builtin: hash
+
+   Compute and return the hash value of an object *o*.  On failure, return ``-1``.
+   This is the equivalent of the Python expression ``hash(o)``.
+
+
+.. cfunction:: int PyObject_IsTrue(PyObject *o)
+
+   Returns ``1`` if the object *o* is considered to be true, and ``0`` otherwise.
+   This is equivalent to the Python expression ``not not o``.  On failure, return
+   ``-1``.
+
+
+.. cfunction:: int PyObject_Not(PyObject *o)
+
+   Returns ``0`` if the object *o* is considered to be true, and ``1`` otherwise.
+   This is equivalent to the Python expression ``not o``.  On failure, return
+   ``-1``.
+
+
+.. cfunction:: PyObject* PyObject_Type(PyObject *o)
+
+   .. index:: builtin: type
+
+   When *o* is non-*NULL*, returns a type object corresponding to the object type
+   of object *o*. On failure, raises :exc:`SystemError` and returns *NULL*.  This
+   is equivalent to the Python expression ``type(o)``. This function increments the
+   reference count of the return value. There's really no reason to use this
+   function instead of the common expression ``o->ob_type``, which returns a
+   pointer of type :ctype:`PyTypeObject\*`, except when the incremented reference
+   count is needed.
+
+
+.. cfunction:: int PyObject_TypeCheck(PyObject *o, PyTypeObject *type)
+
+   Return true if the object *o* is of type *type* or a subtype of *type*.  Both
+   parameters must be non-*NULL*.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: Py_ssize_t PyObject_Length(PyObject *o)
+               Py_ssize_t PyObject_Size(PyObject *o)
+
+   .. index:: builtin: len
+
+   Return the length of object *o*.  If the object *o* provides either the sequence
+   and mapping protocols, the sequence length is returned.  On error, ``-1`` is
+   returned.  This is the equivalent to the Python expression ``len(o)``.
+
+
+.. cfunction:: PyObject* PyObject_GetItem(PyObject *o, PyObject *key)
+
+   Return element of *o* corresponding to the object *key* or *NULL* on failure.
+   This is the equivalent of the Python expression ``o[key]``.
+
+
+.. cfunction:: int PyObject_SetItem(PyObject *o, PyObject *key, PyObject *v)
+
+   Map the object *key* to the value *v*.  Returns ``-1`` on failure.  This is the
+   equivalent of the Python statement ``o[key] = v``.
+
+
+.. cfunction:: int PyObject_DelItem(PyObject *o, PyObject *key)
+
+   Delete the mapping for *key* from *o*.  Returns ``-1`` on failure. This is the
+   equivalent of the Python statement ``del o[key]``.
+
+
+.. cfunction:: int PyObject_AsFileDescriptor(PyObject *o)
+
+   Derives a file-descriptor from a Python object.  If the object is an integer or
+   long integer, its value is returned.  If not, the object's :meth:`fileno` method
+   is called if it exists; the method must return an integer or long integer, which
+   is returned as the file descriptor value.  Returns ``-1`` on failure.
+
+
+.. cfunction:: PyObject* PyObject_Dir(PyObject *o)
+
+   This is equivalent to the Python expression ``dir(o)``, returning a (possibly
+   empty) list of strings appropriate for the object argument, or *NULL* if there
+   was an error.  If the argument is *NULL*, this is like the Python ``dir()``,
+   returning the names of the current locals; in this case, if no execution frame
+   is active then *NULL* is returned but :cfunc:`PyErr_Occurred` will return false.
+
+
+.. cfunction:: PyObject* PyObject_GetIter(PyObject *o)
+
+   This is equivalent to the Python expression ``iter(o)``. It returns a new
+   iterator for the object argument, or the object  itself if the object is already
+   an iterator.  Raises :exc:`TypeError` and returns *NULL* if the object cannot be
+   iterated.
+
+
+.. _number:
+
+Number Protocol
+===============
+
+
+.. cfunction:: int PyNumber_Check(PyObject *o)
+
+   Returns ``1`` if the object *o* provides numeric protocols, and false otherwise.
+   This function always succeeds.
+
+
+.. cfunction:: PyObject* PyNumber_Add(PyObject *o1, PyObject *o2)
+
+   Returns the result of adding *o1* and *o2*, or *NULL* on failure.  This is the
+   equivalent of the Python expression ``o1 + o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Subtract(PyObject *o1, PyObject *o2)
+
+   Returns the result of subtracting *o2* from *o1*, or *NULL* on failure.  This is
+   the equivalent of the Python expression ``o1 - o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Multiply(PyObject *o1, PyObject *o2)
+
+   Returns the result of multiplying *o1* and *o2*, or *NULL* on failure.  This is
+   the equivalent of the Python expression ``o1 * o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Divide(PyObject *o1, PyObject *o2)
+
+   Returns the result of dividing *o1* by *o2*, or *NULL* on failure.  This is the
+   equivalent of the Python expression ``o1 / o2``.
+
+
+.. cfunction:: PyObject* PyNumber_FloorDivide(PyObject *o1, PyObject *o2)
+
+   Return the floor of *o1* divided by *o2*, or *NULL* on failure.  This is
+   equivalent to the "classic" division of integers.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyNumber_TrueDivide(PyObject *o1, PyObject *o2)
+
+   Return a reasonable approximation for the mathematical value of *o1* divided by
+   *o2*, or *NULL* on failure.  The return value is "approximate" because binary
+   floating point numbers are approximate; it is not possible to represent all real
+   numbers in base two.  This function can return a floating point value when
+   passed two integers.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyNumber_Remainder(PyObject *o1, PyObject *o2)
+
+   Returns the remainder of dividing *o1* by *o2*, or *NULL* on failure.  This is
+   the equivalent of the Python expression ``o1 % o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Divmod(PyObject *o1, PyObject *o2)
+
+   .. index:: builtin: divmod
+
+   See the built-in function :func:`divmod`. Returns *NULL* on failure.  This is
+   the equivalent of the Python expression ``divmod(o1, o2)``.
+
+
+.. cfunction:: PyObject* PyNumber_Power(PyObject *o1, PyObject *o2, PyObject *o3)
+
+   .. index:: builtin: pow
+
+   See the built-in function :func:`pow`. Returns *NULL* on failure.  This is the
+   equivalent of the Python expression ``pow(o1, o2, o3)``, where *o3* is optional.
+   If *o3* is to be ignored, pass :cdata:`Py_None` in its place (passing *NULL* for
+   *o3* would cause an illegal memory access).
+
+
+.. cfunction:: PyObject* PyNumber_Negative(PyObject *o)
+
+   Returns the negation of *o* on success, or *NULL* on failure. This is the
+   equivalent of the Python expression ``-o``.
+
+
+.. cfunction:: PyObject* PyNumber_Positive(PyObject *o)
+
+   Returns *o* on success, or *NULL* on failure.  This is the equivalent of the
+   Python expression ``+o``.
+
+
+.. cfunction:: PyObject* PyNumber_Absolute(PyObject *o)
+
+   .. index:: builtin: abs
+
+   Returns the absolute value of *o*, or *NULL* on failure.  This is the equivalent
+   of the Python expression ``abs(o)``.
+
+
+.. cfunction:: PyObject* PyNumber_Invert(PyObject *o)
+
+   Returns the bitwise negation of *o* on success, or *NULL* on failure.  This is
+   the equivalent of the Python expression ``~o``.
+
+
+.. cfunction:: PyObject* PyNumber_Lshift(PyObject *o1, PyObject *o2)
+
+   Returns the result of left shifting *o1* by *o2* on success, or *NULL* on
+   failure.  This is the equivalent of the Python expression ``o1 << o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Rshift(PyObject *o1, PyObject *o2)
+
+   Returns the result of right shifting *o1* by *o2* on success, or *NULL* on
+   failure.  This is the equivalent of the Python expression ``o1 >> o2``.
+
+
+.. cfunction:: PyObject* PyNumber_And(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise and" of *o1* and *o2* on success and *NULL* on failure.
+   This is the equivalent of the Python expression ``o1 & o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Xor(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise exclusive or" of *o1* by *o2* on success, or *NULL* on
+   failure.  This is the equivalent of the Python expression ``o1 ^ o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Or(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise or" of *o1* and *o2* on success, or *NULL* on failure.
+   This is the equivalent of the Python expression ``o1 | o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceAdd(PyObject *o1, PyObject *o2)
+
+   Returns the result of adding *o1* and *o2*, or *NULL* on failure.  The operation
+   is done *in-place* when *o1* supports it.  This is the equivalent of the Python
+   statement ``o1 += o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceSubtract(PyObject *o1, PyObject *o2)
+
+   Returns the result of subtracting *o2* from *o1*, or *NULL* on failure.  The
+   operation is done *in-place* when *o1* supports it.  This is the equivalent of
+   the Python statement ``o1 -= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceMultiply(PyObject *o1, PyObject *o2)
+
+   Returns the result of multiplying *o1* and *o2*, or *NULL* on failure.  The
+   operation is done *in-place* when *o1* supports it.  This is the equivalent of
+   the Python statement ``o1 *= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceDivide(PyObject *o1, PyObject *o2)
+
+   Returns the result of dividing *o1* by *o2*, or *NULL* on failure.  The
+   operation is done *in-place* when *o1* supports it. This is the equivalent of
+   the Python statement ``o1 /= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceFloorDivide(PyObject *o1, PyObject *o2)
+
+   Returns the mathematical floor of dividing *o1* by *o2*, or *NULL* on failure.
+   The operation is done *in-place* when *o1* supports it.  This is the equivalent
+   of the Python statement ``o1 //= o2``.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceTrueDivide(PyObject *o1, PyObject *o2)
+
+   Return a reasonable approximation for the mathematical value of *o1* divided by
+   *o2*, or *NULL* on failure.  The return value is "approximate" because binary
+   floating point numbers are approximate; it is not possible to represent all real
+   numbers in base two.  This function can return a floating point value when
+   passed two integers.  The operation is done *in-place* when *o1* supports it.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceRemainder(PyObject *o1, PyObject *o2)
+
+   Returns the remainder of dividing *o1* by *o2*, or *NULL* on failure.  The
+   operation is done *in-place* when *o1* supports it.  This is the equivalent of
+   the Python statement ``o1 %= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlacePower(PyObject *o1, PyObject *o2, PyObject *o3)
+
+   .. index:: builtin: pow
+
+   See the built-in function :func:`pow`. Returns *NULL* on failure.  The operation
+   is done *in-place* when *o1* supports it.  This is the equivalent of the Python
+   statement ``o1 **= o2`` when o3 is :cdata:`Py_None`, or an in-place variant of
+   ``pow(o1, o2, o3)`` otherwise. If *o3* is to be ignored, pass :cdata:`Py_None`
+   in its place (passing *NULL* for *o3* would cause an illegal memory access).
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceLshift(PyObject *o1, PyObject *o2)
+
+   Returns the result of left shifting *o1* by *o2* on success, or *NULL* on
+   failure.  The operation is done *in-place* when *o1* supports it.  This is the
+   equivalent of the Python statement ``o1 <<= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceRshift(PyObject *o1, PyObject *o2)
+
+   Returns the result of right shifting *o1* by *o2* on success, or *NULL* on
+   failure.  The operation is done *in-place* when *o1* supports it.  This is the
+   equivalent of the Python statement ``o1 >>= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceAnd(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise and" of *o1* and *o2* on success and *NULL* on failure. The
+   operation is done *in-place* when *o1* supports it.  This is the equivalent of
+   the Python statement ``o1 &= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceXor(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise exclusive or" of *o1* by *o2* on success, or *NULL* on
+   failure.  The operation is done *in-place* when *o1* supports it.  This is the
+   equivalent of the Python statement ``o1 ^= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_InPlaceOr(PyObject *o1, PyObject *o2)
+
+   Returns the "bitwise or" of *o1* and *o2* on success, or *NULL* on failure.  The
+   operation is done *in-place* when *o1* supports it.  This is the equivalent of
+   the Python statement ``o1 |= o2``.
+
+
+.. cfunction:: PyObject* PyNumber_Int(PyObject *o)
+
+   .. index:: builtin: int
+
+   Returns the *o* converted to an integer object on success, or *NULL* on failure.
+   If the argument is outside the integer range a long object will be returned
+   instead. This is the equivalent of the Python expression ``int(o)``.
+
+
+.. cfunction:: PyObject* PyNumber_Long(PyObject *o)
+
+   .. index:: builtin: long
+
+   Returns the *o* converted to a long integer object on success, or *NULL* on
+   failure.  This is the equivalent of the Python expression ``long(o)``.
+
+
+.. cfunction:: PyObject* PyNumber_Float(PyObject *o)
+
+   .. index:: builtin: float
+
+   Returns the *o* converted to a float object on success, or *NULL* on failure.
+   This is the equivalent of the Python expression ``float(o)``.
+
+
+.. cfunction:: PyObject* PyNumber_Index(PyObject *o)
+
+   Returns the *o* converted to a Python int or long on success or *NULL* with a
+   TypeError exception raised on failure.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: Py_ssize_t PyNumber_AsSsize_t(PyObject *o, PyObject *exc)
+
+   Returns *o* converted to a Py_ssize_t value if *o* can be interpreted as an
+   integer. If *o* can be converted to a Python int or long but the attempt to
+   convert to a Py_ssize_t value would raise an :exc:`OverflowError`, then the
+   *exc* argument is the type of exception that will be raised (usually
+   :exc:`IndexError` or :exc:`OverflowError`).  If *exc* is *NULL*, then the
+   exception is cleared and the value is clipped to *PY_SSIZE_T_MIN* for a negative
+   integer or *PY_SSIZE_T_MAX* for a positive integer.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: int PyIndex_Check(PyObject *o)
+
+   Returns True if *o* is an index integer (has the nb_index slot of  the
+   tp_as_number structure filled in).
+
+   .. versionadded:: 2.5
+
+
+.. _sequence:
+
+Sequence Protocol
+=================
+
+
+.. cfunction:: int PySequence_Check(PyObject *o)
+
+   Return ``1`` if the object provides sequence protocol, and ``0`` otherwise.
+   This function always succeeds.
+
+
+.. cfunction:: Py_ssize_t PySequence_Size(PyObject *o)
+
+   .. index:: builtin: len
+
+   Returns the number of objects in sequence *o* on success, and ``-1`` on failure.
+   For objects that do not provide sequence protocol, this is equivalent to the
+   Python expression ``len(o)``.
+
+
+.. cfunction:: Py_ssize_t PySequence_Length(PyObject *o)
+
+   Alternate name for :cfunc:`PySequence_Size`.
+
+
+.. cfunction:: PyObject* PySequence_Concat(PyObject *o1, PyObject *o2)
+
+   Return the concatenation of *o1* and *o2* on success, and *NULL* on failure.
+   This is the equivalent of the Python expression ``o1 + o2``.
+
+
+.. cfunction:: PyObject* PySequence_Repeat(PyObject *o, Py_ssize_t count)
+
+   Return the result of repeating sequence object *o* *count* times, or *NULL* on
+   failure.  This is the equivalent of the Python expression ``o * count``.
+
+
+.. cfunction:: PyObject* PySequence_InPlaceConcat(PyObject *o1, PyObject *o2)
+
+   Return the concatenation of *o1* and *o2* on success, and *NULL* on failure.
+   The operation is done *in-place* when *o1* supports it.  This is the equivalent
+   of the Python expression ``o1 += o2``.
+
+
+.. cfunction:: PyObject* PySequence_InPlaceRepeat(PyObject *o, Py_ssize_t count)
+
+   Return the result of repeating sequence object *o* *count* times, or *NULL* on
+   failure.  The operation is done *in-place* when *o* supports it.  This is the
+   equivalent of the Python expression ``o *= count``.
+
+
+.. cfunction:: PyObject* PySequence_GetItem(PyObject *o, Py_ssize_t i)
+
+   Return the *i*th element of *o*, or *NULL* on failure. This is the equivalent of
+   the Python expression ``o[i]``.
+
+
+.. cfunction:: PyObject* PySequence_GetSlice(PyObject *o, Py_ssize_t i1, Py_ssize_t i2)
+
+   Return the slice of sequence object *o* between *i1* and *i2*, or *NULL* on
+   failure. This is the equivalent of the Python expression ``o[i1:i2]``.
+
+
+.. cfunction:: int PySequence_SetItem(PyObject *o, Py_ssize_t i, PyObject *v)
+
+   Assign object *v* to the *i*th element of *o*.  Returns ``-1`` on failure.  This
+   is the equivalent of the Python statement ``o[i] = v``.  This function *does
+   not* steal a reference to *v*.
+
+
+.. cfunction:: int PySequence_DelItem(PyObject *o, Py_ssize_t i)
+
+   Delete the *i*th element of object *o*.  Returns ``-1`` on failure.  This is the
+   equivalent of the Python statement ``del o[i]``.
+
+
+.. cfunction:: int PySequence_SetSlice(PyObject *o, Py_ssize_t i1, Py_ssize_t i2, PyObject *v)
+
+   Assign the sequence object *v* to the slice in sequence object *o* from *i1* to
+   *i2*.  This is the equivalent of the Python statement ``o[i1:i2] = v``.
+
+
+.. cfunction:: int PySequence_DelSlice(PyObject *o, Py_ssize_t i1, Py_ssize_t i2)
+
+   Delete the slice in sequence object *o* from *i1* to *i2*.  Returns ``-1`` on
+   failure.  This is the equivalent of the Python statement ``del o[i1:i2]``.
+
+
+.. cfunction:: Py_ssize_t PySequence_Count(PyObject *o, PyObject *value)
+
+   Return the number of occurrences of *value* in *o*, that is, return the number
+   of keys for which ``o[key] == value``.  On failure, return ``-1``.  This is
+   equivalent to the Python expression ``o.count(value)``.
+
+
+.. cfunction:: int PySequence_Contains(PyObject *o, PyObject *value)
+
+   Determine if *o* contains *value*.  If an item in *o* is equal to *value*,
+   return ``1``, otherwise return ``0``. On error, return ``-1``.  This is
+   equivalent to the Python expression ``value in o``.
+
+
+.. cfunction:: Py_ssize_t PySequence_Index(PyObject *o, PyObject *value)
+
+   Return the first index *i* for which ``o[i] == value``.  On error, return
+   ``-1``.    This is equivalent to the Python expression ``o.index(value)``.
+
+
+.. cfunction:: PyObject* PySequence_List(PyObject *o)
+
+   Return a list object with the same contents as the arbitrary sequence *o*.  The
+   returned list is guaranteed to be new.
+
+
+.. cfunction:: PyObject* PySequence_Tuple(PyObject *o)
+
+   .. index:: builtin: tuple
+
+   Return a tuple object with the same contents as the arbitrary sequence *o* or
+   *NULL* on failure.  If *o* is a tuple, a new reference will be returned,
+   otherwise a tuple will be constructed with the appropriate contents.  This is
+   equivalent to the Python expression ``tuple(o)``.
+
+
+.. cfunction:: PyObject* PySequence_Fast(PyObject *o, const char *m)
+
+   Returns the sequence *o* as a tuple, unless it is already a tuple or list, in
+   which case *o* is returned.  Use :cfunc:`PySequence_Fast_GET_ITEM` to access the
+   members of the result.  Returns *NULL* on failure.  If the object is not a
+   sequence, raises :exc:`TypeError` with *m* as the message text.
+
+
+.. cfunction:: PyObject* PySequence_Fast_GET_ITEM(PyObject *o, Py_ssize_t i)
+
+   Return the *i*th element of *o*, assuming that *o* was returned by
+   :cfunc:`PySequence_Fast`, *o* is not *NULL*, and that *i* is within bounds.
+
+
+.. cfunction:: PyObject** PySequence_Fast_ITEMS(PyObject *o)
+
+   Return the underlying array of PyObject pointers.  Assumes that *o* was returned
+   by :cfunc:`PySequence_Fast` and *o* is not *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PySequence_ITEM(PyObject *o, Py_ssize_t i)
+
+   Return the *i*th element of *o* or *NULL* on failure. Macro form of
+   :cfunc:`PySequence_GetItem` but without checking that
+   :cfunc:`PySequence_Check(o)` is true and without adjustment for negative
+   indices.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: Py_ssize_t PySequence_Fast_GET_SIZE(PyObject *o)
+
+   Returns the length of *o*, assuming that *o* was returned by
+   :cfunc:`PySequence_Fast` and that *o* is not *NULL*.  The size can also be
+   gotten by calling :cfunc:`PySequence_Size` on *o*, but
+   :cfunc:`PySequence_Fast_GET_SIZE` is faster because it can assume *o* is a list
+   or tuple.
+
+
+.. _mapping:
+
+Mapping Protocol
+================
+
+
+.. cfunction:: int PyMapping_Check(PyObject *o)
+
+   Return ``1`` if the object provides mapping protocol, and ``0`` otherwise.  This
+   function always succeeds.
+
+
+.. cfunction:: Py_ssize_t PyMapping_Length(PyObject *o)
+
+   .. index:: builtin: len
+
+   Returns the number of keys in object *o* on success, and ``-1`` on failure.  For
+   objects that do not provide mapping protocol, this is equivalent to the Python
+   expression ``len(o)``.
+
+
+.. cfunction:: int PyMapping_DelItemString(PyObject *o, char *key)
+
+   Remove the mapping for object *key* from the object *o*. Return ``-1`` on
+   failure.  This is equivalent to the Python statement ``del o[key]``.
+
+
+.. cfunction:: int PyMapping_DelItem(PyObject *o, PyObject *key)
+
+   Remove the mapping for object *key* from the object *o*. Return ``-1`` on
+   failure.  This is equivalent to the Python statement ``del o[key]``.
+
+
+.. cfunction:: int PyMapping_HasKeyString(PyObject *o, char *key)
+
+   On success, return ``1`` if the mapping object has the key *key* and ``0``
+   otherwise.  This is equivalent to the Python expression ``o.has_key(key)``.
+   This function always succeeds.
+
+
+.. cfunction:: int PyMapping_HasKey(PyObject *o, PyObject *key)
+
+   Return ``1`` if the mapping object has the key *key* and ``0`` otherwise.  This
+   is equivalent to the Python expression ``o.has_key(key)``.  This function always
+   succeeds.
+
+
+.. cfunction:: PyObject* PyMapping_Keys(PyObject *o)
+
+   On success, return a list of the keys in object *o*.  On failure, return *NULL*.
+   This is equivalent to the Python expression ``o.keys()``.
+
+
+.. cfunction:: PyObject* PyMapping_Values(PyObject *o)
+
+   On success, return a list of the values in object *o*.  On failure, return
+   *NULL*. This is equivalent to the Python expression ``o.values()``.
+
+
+.. cfunction:: PyObject* PyMapping_Items(PyObject *o)
+
+   On success, return a list of the items in object *o*, where each item is a tuple
+   containing a key-value pair.  On failure, return *NULL*. This is equivalent to
+   the Python expression ``o.items()``.
+
+
+.. cfunction:: PyObject* PyMapping_GetItemString(PyObject *o, char *key)
+
+   Return element of *o* corresponding to the object *key* or *NULL* on failure.
+   This is the equivalent of the Python expression ``o[key]``.
+
+
+.. cfunction:: int PyMapping_SetItemString(PyObject *o, char *key, PyObject *v)
+
+   Map the object *key* to the value *v* in object *o*. Returns ``-1`` on failure.
+   This is the equivalent of the Python statement ``o[key] = v``.
+
+
+.. _iterator:
+
+Iterator Protocol
+=================
+
+.. versionadded:: 2.2
+
+There are only a couple of functions specifically for working with iterators.
+
+
+.. cfunction:: int PyIter_Check(PyObject *o)
+
+   Return true if the object *o* supports the iterator protocol.
+
+
+.. cfunction:: PyObject* PyIter_Next(PyObject *o)
+
+   Return the next value from the iteration *o*.  If the object is an iterator,
+   this retrieves the next value from the iteration, and returns *NULL* with no
+   exception set if there are no remaining items.  If the object is not an
+   iterator, :exc:`TypeError` is raised, or if there is an error in retrieving the
+   item, returns *NULL* and passes along the exception.
+
+To write a loop which iterates over an iterator, the C code should look
+something like this::
+
+   PyObject *iterator = PyObject_GetIter(obj);
+   PyObject *item;
+
+   if (iterator == NULL) {
+       /* propagate error */
+   }
+
+   while (item = PyIter_Next(iterator)) {
+       /* do something with item */
+       ...
+       /* release reference when done */
+       Py_DECREF(item);
+   }
+
+   Py_DECREF(iterator);
+
+   if (PyErr_Occurred()) {
+       /* propagate error */
+   }
+   else {
+       /* continue doing useful work */
+   }
+
+
+.. _abstract-buffer:
+
+Buffer Protocol
+===============
+
+
+.. cfunction:: int PyObject_AsCharBuffer(PyObject *obj, const char **buffer, Py_ssize_t *buffer_len)
+
+   Returns a pointer to a read-only memory location useable as character- based
+   input.  The *obj* argument must support the single-segment character buffer
+   interface.  On success, returns ``0``, sets *buffer* to the memory location and
+   *buffer_len* to the buffer length.  Returns ``-1`` and sets a :exc:`TypeError`
+   on error.
+
+   .. versionadded:: 1.6
+
+
+.. cfunction:: int PyObject_AsReadBuffer(PyObject *obj, const void **buffer, Py_ssize_t *buffer_len)
+
+   Returns a pointer to a read-only memory location containing arbitrary data.  The
+   *obj* argument must support the single-segment readable buffer interface.  On
+   success, returns ``0``, sets *buffer* to the memory location and *buffer_len* to
+   the buffer length.  Returns ``-1`` and sets a :exc:`TypeError` on error.
+
+   .. versionadded:: 1.6
+
+
+.. cfunction:: int PyObject_CheckReadBuffer(PyObject *o)
+
+   Returns ``1`` if *o* supports the single-segment readable buffer interface.
+   Otherwise returns ``0``.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyObject_AsWriteBuffer(PyObject *obj, void **buffer, Py_ssize_t *buffer_len)
+
+   Returns a pointer to a writeable memory location.  The *obj* argument must
+   support the single-segment, character buffer interface.  On success, returns
+   ``0``, sets *buffer* to the memory location and *buffer_len* to the buffer
+   length.  Returns ``-1`` and sets a :exc:`TypeError` on error.
+
+   .. versionadded:: 1.6
+
diff --git a/Doc/c-api/concrete.rst b/Doc/c-api/concrete.rst
new file mode 100644
index 0000000..052785c
--- /dev/null
+++ b/Doc/c-api/concrete.rst
@@ -0,0 +1,3676 @@
+.. highlightlang:: c
+
+
+.. _concrete:
+
+**********************
+Concrete Objects Layer
+**********************
+
+The functions in this chapter are specific to certain Python object types.
+Passing them an object of the wrong type is not a good idea; if you receive an
+object from a Python program and you are not sure that it has the right type,
+you must perform a type check first; for example, to check that an object is a
+dictionary, use :cfunc:`PyDict_Check`.  The chapter is structured like the
+"family tree" of Python object types.
+
+.. warning::
+
+   While the functions described in this chapter carefully check the type of the
+   objects which are passed in, many of them do not check for *NULL* being passed
+   instead of a valid object.  Allowing *NULL* to be passed in can cause memory
+   access violations and immediate termination of the interpreter.
+
+
+.. _fundamental:
+
+Fundamental Objects
+===================
+
+This section describes Python type objects and the singleton object ``None``.
+
+
+.. _typeobjects:
+
+Type Objects
+------------
+
+.. index:: object: type
+
+
+.. ctype:: PyTypeObject
+
+   The C structure of the objects used to describe built-in types.
+
+
+.. cvar:: PyObject* PyType_Type
+
+   .. index:: single: TypeType (in module types)
+
+   This is the type object for type objects; it is the same object as ``type`` and
+   ``types.TypeType`` in the Python layer.
+
+
+.. cfunction:: int PyType_Check(PyObject *o)
+
+   Return true if the object *o* is a type object, including instances of types
+   derived from the standard type object.  Return false in all other cases.
+
+
+.. cfunction:: int PyType_CheckExact(PyObject *o)
+
+   Return true if the object *o* is a type object, but not a subtype of the
+   standard type object.  Return false in all other cases.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyType_HasFeature(PyObject *o, int feature)
+
+   Return true if the type object *o* sets the feature *feature*.  Type features
+   are denoted by single bit flags.
+
+
+.. cfunction:: int PyType_IS_GC(PyObject *o)
+
+   Return true if the type object includes support for the cycle detector; this
+   tests the type flag :const:`Py_TPFLAGS_HAVE_GC`.
+
+   .. versionadded:: 2.0
+
+
+.. cfunction:: int PyType_IsSubtype(PyTypeObject *a, PyTypeObject *b)
+
+   Return true if *a* is a subtype of *b*.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyType_GenericAlloc(PyTypeObject *type, Py_ssize_t nitems)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyType_GenericNew(PyTypeObject *type, PyObject *args, PyObject *kwds)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyType_Ready(PyTypeObject *type)
+
+   Finalize a type object.  This should be called on all type objects to finish
+   their initialization.  This function is responsible for adding inherited slots
+   from a type's base class.  Return ``0`` on success, or return ``-1`` and sets an
+   exception on error.
+
+   .. versionadded:: 2.2
+
+
+.. _noneobject:
+
+The None Object
+---------------
+
+.. index:: object: None
+
+Note that the :ctype:`PyTypeObject` for ``None`` is not directly exposed in the
+Python/C API.  Since ``None`` is a singleton, testing for object identity (using
+``==`` in C) is sufficient. There is no :cfunc:`PyNone_Check` function for the
+same reason.
+
+
+.. cvar:: PyObject* Py_None
+
+   The Python ``None`` object, denoting lack of value.  This object has no methods.
+   It needs to be treated just like any other object with respect to reference
+   counts.
+
+
+.. cmacro:: Py_RETURN_NONE
+
+   Properly handle returning :cdata:`Py_None` from within a C function.
+
+   .. versionadded:: 2.4
+
+
+.. _numericobjects:
+
+Numeric Objects
+===============
+
+.. index:: object: numeric
+
+
+.. _intobjects:
+
+Plain Integer Objects
+---------------------
+
+.. index:: object: integer
+
+
+.. ctype:: PyIntObject
+
+   This subtype of :ctype:`PyObject` represents a Python integer object.
+
+
+.. cvar:: PyTypeObject PyInt_Type
+
+   .. index:: single: IntType (in modules types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python plain integer type.
+   This is the same object as ``int`` and ``types.IntType``.
+
+
+.. cfunction:: int PyInt_Check(PyObject *o)
+
+   Return true if *o* is of type :cdata:`PyInt_Type` or a subtype of
+   :cdata:`PyInt_Type`.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyInt_CheckExact(PyObject *o)
+
+   Return true if *o* is of type :cdata:`PyInt_Type`, but not a subtype of
+   :cdata:`PyInt_Type`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyInt_FromString(char *str, char **pend, int base)
+
+   Return a new :ctype:`PyIntObject` or :ctype:`PyLongObject` based on the string
+   value in *str*, which is interpreted according to the radix in *base*.  If
+   *pend* is non-*NULL*, ``*pend`` will point to the first character in *str* which
+   follows the representation of the number.  If *base* is ``0``, the radix will be
+   determined based on the leading characters of *str*: if *str* starts with
+   ``'0x'`` or ``'0X'``, radix 16 will be used; if *str* starts with ``'0'``, radix
+   8 will be used; otherwise radix 10 will be used.  If *base* is not ``0``, it
+   must be between ``2`` and ``36``, inclusive.  Leading spaces are ignored.  If
+   there are no digits, :exc:`ValueError` will be raised.  If the string represents
+   a number too large to be contained within the machine's :ctype:`long int` type
+   and overflow warnings are being suppressed, a :ctype:`PyLongObject` will be
+   returned.  If overflow warnings are not being suppressed, *NULL* will be
+   returned in this case.
+
+
+.. cfunction:: PyObject* PyInt_FromLong(long ival)
+
+   Create a new integer object with a value of *ival*.
+
+   The current implementation keeps an array of integer objects for all integers
+   between ``-5`` and ``256``, when you create an int in that range you actually
+   just get back a reference to the existing object. So it should be possible to
+   change the value of ``1``.  I suspect the behaviour of Python in this case is
+   undefined. :-)
+
+
+.. cfunction:: PyObject* PyInt_FromSsize_t(Py_ssize_t ival)
+
+   Create a new integer object with a value of *ival*. If the value exceeds
+   ``LONG_MAX``, a long integer object is returned.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: long PyInt_AsLong(PyObject *io)
+
+   Will first attempt to cast the object to a :ctype:`PyIntObject`, if it is not
+   already one, and then return its value. If there is an error, ``-1`` is
+   returned, and the caller should check ``PyErr_Occurred()`` to find out whether
+   there was an error, or whether the value just happened to be -1.
+
+
+.. cfunction:: long PyInt_AS_LONG(PyObject *io)
+
+   Return the value of the object *io*.  No error checking is performed.
+
+
+.. cfunction:: unsigned long PyInt_AsUnsignedLongMask(PyObject *io)
+
+   Will first attempt to cast the object to a :ctype:`PyIntObject` or
+   :ctype:`PyLongObject`, if it is not already one, and then return its value as
+   unsigned long.  This function does not check for overflow.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: unsigned PY_LONG_LONG PyInt_AsUnsignedLongLongMask(PyObject *io)
+
+   Will first attempt to cast the object to a :ctype:`PyIntObject` or
+   :ctype:`PyLongObject`, if it is not already one, and then return its value as
+   unsigned long long, without checking for overflow.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: Py_ssize_t PyInt_AsSsize_t(PyObject *io)
+
+   Will first attempt to cast the object to a :ctype:`PyIntObject` or
+   :ctype:`PyLongObject`, if it is not already one, and then return its value as
+   :ctype:`Py_ssize_t`.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: long PyInt_GetMax()
+
+   .. index:: single: LONG_MAX
+
+   Return the system's idea of the largest integer it can handle
+   (:const:`LONG_MAX`, as defined in the system header files).
+
+
+.. _boolobjects:
+
+Boolean Objects
+---------------
+
+Booleans in Python are implemented as a subclass of integers.  There are only
+two booleans, :const:`Py_False` and :const:`Py_True`.  As such, the normal
+creation and deletion functions don't apply to booleans.  The following macros
+are available, however.
+
+
+.. cfunction:: int PyBool_Check(PyObject *o)
+
+   Return true if *o* is of type :cdata:`PyBool_Type`.
+
+   .. versionadded:: 2.3
+
+
+.. cvar:: PyObject* Py_False
+
+   The Python ``False`` object.  This object has no methods.  It needs to be
+   treated just like any other object with respect to reference counts.
+
+
+.. cvar:: PyObject* Py_True
+
+   The Python ``True`` object.  This object has no methods.  It needs to be treated
+   just like any other object with respect to reference counts.
+
+
+.. cmacro:: Py_RETURN_FALSE
+
+   Return :const:`Py_False` from a function, properly incrementing its reference
+   count.
+
+   .. versionadded:: 2.4
+
+
+.. cmacro:: Py_RETURN_TRUE
+
+   Return :const:`Py_True` from a function, properly incrementing its reference
+   count.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyBool_FromLong(long v)
+
+   Return a new reference to :const:`Py_True` or :const:`Py_False` depending on the
+   truth value of *v*.
+
+   .. versionadded:: 2.3
+
+
+.. _longobjects:
+
+Long Integer Objects
+--------------------
+
+.. index:: object: long integer
+
+
+.. ctype:: PyLongObject
+
+   This subtype of :ctype:`PyObject` represents a Python long integer object.
+
+
+.. cvar:: PyTypeObject PyLong_Type
+
+   .. index:: single: LongType (in modules types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python long integer type.
+   This is the same object as ``long`` and ``types.LongType``.
+
+
+.. cfunction:: int PyLong_Check(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyLongObject` or a subtype of
+   :ctype:`PyLongObject`.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyLong_CheckExact(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyLongObject`, but not a subtype of
+   :ctype:`PyLongObject`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyLong_FromLong(long v)
+
+   Return a new :ctype:`PyLongObject` object from *v*, or *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyLong_FromUnsignedLong(unsigned long v)
+
+   Return a new :ctype:`PyLongObject` object from a C :ctype:`unsigned long`, or
+   *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyLong_FromLongLong(PY_LONG_LONG v)
+
+   Return a new :ctype:`PyLongObject` object from a C :ctype:`long long`, or *NULL*
+   on failure.
+
+
+.. cfunction:: PyObject* PyLong_FromUnsignedLongLong(unsigned PY_LONG_LONG v)
+
+   Return a new :ctype:`PyLongObject` object from a C :ctype:`unsigned long long`,
+   or *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyLong_FromDouble(double v)
+
+   Return a new :ctype:`PyLongObject` object from the integer part of *v*, or
+   *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyLong_FromString(char *str, char **pend, int base)
+
+   Return a new :ctype:`PyLongObject` based on the string value in *str*, which is
+   interpreted according to the radix in *base*.  If *pend* is non-*NULL*,
+   ``*pend`` will point to the first character in *str* which follows the
+   representation of the number.  If *base* is ``0``, the radix will be determined
+   based on the leading characters of *str*: if *str* starts with ``'0x'`` or
+   ``'0X'``, radix 16 will be used; if *str* starts with ``'0'``, radix 8 will be
+   used; otherwise radix 10 will be used.  If *base* is not ``0``, it must be
+   between ``2`` and ``36``, inclusive.  Leading spaces are ignored.  If there are
+   no digits, :exc:`ValueError` will be raised.
+
+
+.. cfunction:: PyObject* PyLong_FromUnicode(Py_UNICODE *u, Py_ssize_t length, int base)
+
+   Convert a sequence of Unicode digits to a Python long integer value.  The first
+   parameter, *u*, points to the first character of the Unicode string, *length*
+   gives the number of characters, and *base* is the radix for the conversion.  The
+   radix must be in the range [2, 36]; if it is out of range, :exc:`ValueError`
+   will be raised.
+
+   .. versionadded:: 1.6
+
+
+.. cfunction:: PyObject* PyLong_FromVoidPtr(void *p)
+
+   Create a Python integer or long integer from the pointer *p*. The pointer value
+   can be retrieved from the resulting value using :cfunc:`PyLong_AsVoidPtr`.
+
+   .. versionadded:: 1.5.2
+
+   .. versionchanged:: 2.5
+      If the integer is larger than LONG_MAX, a positive long integer is returned.
+
+
+.. cfunction:: long PyLong_AsLong(PyObject *pylong)
+
+   .. index::
+      single: LONG_MAX
+      single: OverflowError (built-in exception)
+
+   Return a C :ctype:`long` representation of the contents of *pylong*.  If
+   *pylong* is greater than :const:`LONG_MAX`, an :exc:`OverflowError` is raised.
+
+
+.. cfunction:: unsigned long PyLong_AsUnsignedLong(PyObject *pylong)
+
+   .. index::
+      single: ULONG_MAX
+      single: OverflowError (built-in exception)
+
+   Return a C :ctype:`unsigned long` representation of the contents of *pylong*.
+   If *pylong* is greater than :const:`ULONG_MAX`, an :exc:`OverflowError` is
+   raised.
+
+
+.. cfunction:: PY_LONG_LONG PyLong_AsLongLong(PyObject *pylong)
+
+   Return a C :ctype:`long long` from a Python long integer.  If *pylong* cannot be
+   represented as a :ctype:`long long`, an :exc:`OverflowError` will be raised.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: unsigned PY_LONG_LONG PyLong_AsUnsignedLongLong(PyObject *pylong)
+
+   Return a C :ctype:`unsigned long long` from a Python long integer. If *pylong*
+   cannot be represented as an :ctype:`unsigned long long`, an :exc:`OverflowError`
+   will be raised if the value is positive, or a :exc:`TypeError` will be raised if
+   the value is negative.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: unsigned long PyLong_AsUnsignedLongMask(PyObject *io)
+
+   Return a C :ctype:`unsigned long` from a Python long integer, without checking
+   for overflow.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: unsigned PY_LONG_LONG PyLong_AsUnsignedLongLongMask(PyObject *io)
+
+   Return a C :ctype:`unsigned long long` from a Python long integer, without
+   checking for overflow.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: double PyLong_AsDouble(PyObject *pylong)
+
+   Return a C :ctype:`double` representation of the contents of *pylong*.  If
+   *pylong* cannot be approximately represented as a :ctype:`double`, an
+   :exc:`OverflowError` exception is raised and ``-1.0`` will be returned.
+
+
+.. cfunction:: void* PyLong_AsVoidPtr(PyObject *pylong)
+
+   Convert a Python integer or long integer *pylong* to a C :ctype:`void` pointer.
+   If *pylong* cannot be converted, an :exc:`OverflowError` will be raised.  This
+   is only assured to produce a usable :ctype:`void` pointer for values created
+   with :cfunc:`PyLong_FromVoidPtr`.
+
+   .. versionadded:: 1.5.2
+
+   .. versionchanged:: 2.5
+      For values outside 0..LONG_MAX, both signed and unsigned integers are acccepted.
+
+
+.. _floatobjects:
+
+Floating Point Objects
+----------------------
+
+.. index:: object: floating point
+
+
+.. ctype:: PyFloatObject
+
+   This subtype of :ctype:`PyObject` represents a Python floating point object.
+
+
+.. cvar:: PyTypeObject PyFloat_Type
+
+   .. index:: single: FloatType (in modules types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python floating point
+   type.  This is the same object as ``float`` and ``types.FloatType``.
+
+
+.. cfunction:: int PyFloat_Check(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyFloatObject` or a subtype of
+   :ctype:`PyFloatObject`.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyFloat_CheckExact(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyFloatObject`, but not a subtype of
+   :ctype:`PyFloatObject`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyFloat_FromString(PyObject *str)
+
+   Create a :ctype:`PyFloatObject` object based on the string value in *str*, or
+   *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyFloat_FromDouble(double v)
+
+   Create a :ctype:`PyFloatObject` object from *v*, or *NULL* on failure.
+
+
+.. cfunction:: double PyFloat_AsDouble(PyObject *pyfloat)
+
+   Return a C :ctype:`double` representation of the contents of *pyfloat*.  If
+   *pyfloat* is not a Python floating point object but has a :meth:`__float__`
+   method, this method will first be called to convert *pyfloat* into a float.
+
+
+.. cfunction:: double PyFloat_AS_DOUBLE(PyObject *pyfloat)
+
+   Return a C :ctype:`double` representation of the contents of *pyfloat*, but
+   without error checking.
+
+
+.. _complexobjects:
+
+Complex Number Objects
+----------------------
+
+.. index:: object: complex number
+
+Python's complex number objects are implemented as two distinct types when
+viewed from the C API:  one is the Python object exposed to Python programs, and
+the other is a C structure which represents the actual complex number value.
+The API provides functions for working with both.
+
+
+Complex Numbers as C Structures
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Note that the functions which accept these structures as parameters and return
+them as results do so *by value* rather than dereferencing them through
+pointers.  This is consistent throughout the API.
+
+
+.. ctype:: Py_complex
+
+   The C structure which corresponds to the value portion of a Python complex
+   number object.  Most of the functions for dealing with complex number objects
+   use structures of this type as input or output values, as appropriate.  It is
+   defined as::
+
+      typedef struct {
+         double real;
+         double imag;
+      } Py_complex;
+
+
+.. cfunction:: Py_complex _Py_c_sum(Py_complex left, Py_complex right)
+
+   Return the sum of two complex numbers, using the C :ctype:`Py_complex`
+   representation.
+
+
+.. cfunction:: Py_complex _Py_c_diff(Py_complex left, Py_complex right)
+
+   Return the difference between two complex numbers, using the C
+   :ctype:`Py_complex` representation.
+
+
+.. cfunction:: Py_complex _Py_c_neg(Py_complex complex)
+
+   Return the negation of the complex number *complex*, using the C
+   :ctype:`Py_complex` representation.
+
+
+.. cfunction:: Py_complex _Py_c_prod(Py_complex left, Py_complex right)
+
+   Return the product of two complex numbers, using the C :ctype:`Py_complex`
+   representation.
+
+
+.. cfunction:: Py_complex _Py_c_quot(Py_complex dividend, Py_complex divisor)
+
+   Return the quotient of two complex numbers, using the C :ctype:`Py_complex`
+   representation.
+
+
+.. cfunction:: Py_complex _Py_c_pow(Py_complex num, Py_complex exp)
+
+   Return the exponentiation of *num* by *exp*, using the C :ctype:`Py_complex`
+   representation.
+
+
+Complex Numbers as Python Objects
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+
+.. ctype:: PyComplexObject
+
+   This subtype of :ctype:`PyObject` represents a Python complex number object.
+
+
+.. cvar:: PyTypeObject PyComplex_Type
+
+   This instance of :ctype:`PyTypeObject` represents the Python complex number
+   type. It is the same object as ``complex`` and ``types.ComplexType``.
+
+
+.. cfunction:: int PyComplex_Check(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyComplexObject` or a subtype of
+   :ctype:`PyComplexObject`.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyComplex_CheckExact(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyComplexObject`, but not a subtype of
+   :ctype:`PyComplexObject`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyComplex_FromCComplex(Py_complex v)
+
+   Create a new Python complex number object from a C :ctype:`Py_complex` value.
+
+
+.. cfunction:: PyObject* PyComplex_FromDoubles(double real, double imag)
+
+   Return a new :ctype:`PyComplexObject` object from *real* and *imag*.
+
+
+.. cfunction:: double PyComplex_RealAsDouble(PyObject *op)
+
+   Return the real part of *op* as a C :ctype:`double`.
+
+
+.. cfunction:: double PyComplex_ImagAsDouble(PyObject *op)
+
+   Return the imaginary part of *op* as a C :ctype:`double`.
+
+
+.. cfunction:: Py_complex PyComplex_AsCComplex(PyObject *op)
+
+   Return the :ctype:`Py_complex` value of the complex number *op*.
+
+   .. versionchanged:: 2.6
+      If *op* is not a Python complex number object but has a :meth:`__complex__`
+      method, this method will first be called to convert *op* to a Python complex
+      number object.
+
+
+.. _sequenceobjects:
+
+Sequence Objects
+================
+
+.. index:: object: sequence
+
+Generic operations on sequence objects were discussed in the previous chapter;
+this section deals with the specific kinds of sequence objects that are
+intrinsic to the Python language.
+
+
+.. _stringobjects:
+
+String Objects
+--------------
+
+These functions raise :exc:`TypeError` when expecting a string parameter and are
+called with a non-string parameter.
+
+.. index:: object: string
+
+
+.. ctype:: PyStringObject
+
+   This subtype of :ctype:`PyObject` represents a Python string object.
+
+
+.. cvar:: PyTypeObject PyString_Type
+
+   .. index:: single: StringType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python string type; it is
+   the same object as ``str`` and ``types.StringType`` in the Python layer. .
+
+
+.. cfunction:: int PyString_Check(PyObject *o)
+
+   Return true if the object *o* is a string object or an instance of a subtype of
+   the string type.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyString_CheckExact(PyObject *o)
+
+   Return true if the object *o* is a string object, but not an instance of a
+   subtype of the string type.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyString_FromString(const char *v)
+
+   Return a new string object with a copy of the string *v* as value on success,
+   and *NULL* on failure.  The parameter *v* must not be *NULL*; it will not be
+   checked.
+
+
+.. cfunction:: PyObject* PyString_FromStringAndSize(const char *v, Py_ssize_t len)
+
+   Return a new string object with a copy of the string *v* as value and length
+   *len* on success, and *NULL* on failure.  If *v* is *NULL*, the contents of the
+   string are uninitialized.
+
+
+.. cfunction:: PyObject* PyString_FromFormat(const char *format, ...)
+
+   Take a C :cfunc:`printf`\ -style *format* string and a variable number of
+   arguments, calculate the size of the resulting Python string and return a string
+   with the values formatted into it.  The variable arguments must be C types and
+   must correspond exactly to the format characters in the *format* string.  The
+   following format characters are allowed:
+
+   .. % This should be exactly the same as the table in PyErr_Format.
+   .. % One should just refer to the other.
+   .. % The descriptions for %zd and %zu are wrong, but the truth is complicated
+   .. % because not all compilers support the %z width modifier -- we fake it
+   .. % when necessary via interpolating PY_FORMAT_SIZE_T.
+   .. % %u, %lu, %zu should have "new in Python 2.5" blurbs.
+
+   +-------------------+---------------+--------------------------------+
+   | Format Characters | Type          | Comment                        |
+   +===================+===============+================================+
+   | :attr:`%%`        | *n/a*         | The literal % character.       |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%c`        | int           | A single character,            |
+   |                   |               | represented as an C int.       |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%d`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%d")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%u`        | unsigned int  | Exactly equivalent to          |
+   |                   |               | ``printf("%u")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%ld`       | long          | Exactly equivalent to          |
+   |                   |               | ``printf("%ld")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%lu`       | unsigned long | Exactly equivalent to          |
+   |                   |               | ``printf("%lu")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%zd`       | Py_ssize_t    | Exactly equivalent to          |
+   |                   |               | ``printf("%zd")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%zu`       | size_t        | Exactly equivalent to          |
+   |                   |               | ``printf("%zu")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%i`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%i")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%x`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%x")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%s`        | char\*        | A null-terminated C character  |
+   |                   |               | array.                         |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%p`        | void\*        | The hex representation of a C  |
+   |                   |               | pointer. Mostly equivalent to  |
+   |                   |               | ``printf("%p")`` except that   |
+   |                   |               | it is guaranteed to start with |
+   |                   |               | the literal ``0x`` regardless  |
+   |                   |               | of what the platform's         |
+   |                   |               | ``printf`` yields.             |
+   +-------------------+---------------+--------------------------------+
+
+   An unrecognized format character causes all the rest of the format string to be
+   copied as-is to the result string, and any extra arguments discarded.
+
+
+.. cfunction:: PyObject* PyString_FromFormatV(const char *format, va_list vargs)
+
+   Identical to :func:`PyString_FromFormat` except that it takes exactly two
+   arguments.
+
+
+.. cfunction:: Py_ssize_t PyString_Size(PyObject *string)
+
+   Return the length of the string in string object *string*.
+
+
+.. cfunction:: Py_ssize_t PyString_GET_SIZE(PyObject *string)
+
+   Macro form of :cfunc:`PyString_Size` but without error checking.
+
+
+.. cfunction:: char* PyString_AsString(PyObject *string)
+
+   Return a NUL-terminated representation of the contents of *string*.  The pointer
+   refers to the internal buffer of *string*, not a copy.  The data must not be
+   modified in any way, unless the string was just created using
+   ``PyString_FromStringAndSize(NULL, size)``. It must not be deallocated.  If
+   *string* is a Unicode object, this function computes the default encoding of
+   *string* and operates on that.  If *string* is not a string object at all,
+   :cfunc:`PyString_AsString` returns *NULL* and raises :exc:`TypeError`.
+
+
+.. cfunction:: char* PyString_AS_STRING(PyObject *string)
+
+   Macro form of :cfunc:`PyString_AsString` but without error checking.  Only
+   string objects are supported; no Unicode objects should be passed.
+
+
+.. cfunction:: int PyString_AsStringAndSize(PyObject *obj, char **buffer, Py_ssize_t *length)
+
+   Return a NUL-terminated representation of the contents of the object *obj*
+   through the output variables *buffer* and *length*.
+
+   The function accepts both string and Unicode objects as input. For Unicode
+   objects it returns the default encoded version of the object.  If *length* is
+   *NULL*, the resulting buffer may not contain NUL characters; if it does, the
+   function returns ``-1`` and a :exc:`TypeError` is raised.
+
+   The buffer refers to an internal string buffer of *obj*, not a copy. The data
+   must not be modified in any way, unless the string was just created using
+   ``PyString_FromStringAndSize(NULL, size)``.  It must not be deallocated.  If
+   *string* is a Unicode object, this function computes the default encoding of
+   *string* and operates on that.  If *string* is not a string object at all,
+   :cfunc:`PyString_AsStringAndSize` returns ``-1`` and raises :exc:`TypeError`.
+
+
+.. cfunction:: void PyString_Concat(PyObject **string, PyObject *newpart)
+
+   Create a new string object in *\*string* containing the contents of *newpart*
+   appended to *string*; the caller will own the new reference.  The reference to
+   the old value of *string* will be stolen.  If the new string cannot be created,
+   the old reference to *string* will still be discarded and the value of
+   *\*string* will be set to *NULL*; the appropriate exception will be set.
+
+
+.. cfunction:: void PyString_ConcatAndDel(PyObject **string, PyObject *newpart)
+
+   Create a new string object in *\*string* containing the contents of *newpart*
+   appended to *string*.  This version decrements the reference count of *newpart*.
+
+
+.. cfunction:: int _PyString_Resize(PyObject **string, Py_ssize_t newsize)
+
+   A way to resize a string object even though it is "immutable". Only use this to
+   build up a brand new string object; don't use this if the string may already be
+   known in other parts of the code.  It is an error to call this function if the
+   refcount on the input string object is not one. Pass the address of an existing
+   string object as an lvalue (it may be written into), and the new size desired.
+   On success, *\*string* holds the resized string object and ``0`` is returned;
+   the address in *\*string* may differ from its input value.  If the reallocation
+   fails, the original string object at *\*string* is deallocated, *\*string* is
+   set to *NULL*, a memory exception is set, and ``-1`` is returned.
+
+
+.. cfunction:: PyObject* PyString_Format(PyObject *format, PyObject *args)
+
+   Return a new string object from *format* and *args*. Analogous to ``format %
+   args``.  The *args* argument must be a tuple.
+
+
+.. cfunction:: void PyString_InternInPlace(PyObject **string)
+
+   Intern the argument *\*string* in place.  The argument must be the address of a
+   pointer variable pointing to a Python string object.  If there is an existing
+   interned string that is the same as *\*string*, it sets *\*string* to it
+   (decrementing the reference count of the old string object and incrementing the
+   reference count of the interned string object), otherwise it leaves *\*string*
+   alone and interns it (incrementing its reference count).  (Clarification: even
+   though there is a lot of talk about reference counts, think of this function as
+   reference-count-neutral; you own the object after the call if and only if you
+   owned it before the call.)
+
+
+.. cfunction:: PyObject* PyString_InternFromString(const char *v)
+
+   A combination of :cfunc:`PyString_FromString` and
+   :cfunc:`PyString_InternInPlace`, returning either a new string object that has
+   been interned, or a new ("owned") reference to an earlier interned string object
+   with the same value.
+
+
+.. cfunction:: PyObject* PyString_Decode(const char *s, Py_ssize_t size, const char *encoding, const char *errors)
+
+   Create an object by decoding *size* bytes of the encoded buffer *s* using the
+   codec registered for *encoding*.  *encoding* and *errors* have the same meaning
+   as the parameters of the same name in the :func:`unicode` built-in function.
+   The codec to be used is looked up using the Python codec registry.  Return
+   *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyString_AsDecodedObject(PyObject *str, const char *encoding, const char *errors)
+
+   Decode a string object by passing it to the codec registered for *encoding* and
+   return the result as Python object. *encoding* and *errors* have the same
+   meaning as the parameters of the same name in the string :meth:`encode` method.
+   The codec to be used is looked up using the Python codec registry. Return *NULL*
+   if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyString_Encode(const char *s, Py_ssize_t size, const char *encoding, const char *errors)
+
+   Encode the :ctype:`char` buffer of the given size by passing it to the codec
+   registered for *encoding* and return a Python object. *encoding* and *errors*
+   have the same meaning as the parameters of the same name in the string
+   :meth:`encode` method. The codec to be used is looked up using the Python codec
+   registry.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyString_AsEncodedObject(PyObject *str, const char *encoding, const char *errors)
+
+   Encode a string object using the codec registered for *encoding* and return the
+   result as Python object. *encoding* and *errors* have the same meaning as the
+   parameters of the same name in the string :meth:`encode` method. The codec to be
+   used is looked up using the Python codec registry. Return *NULL* if an exception
+   was raised by the codec.
+
+
+.. _unicodeobjects:
+
+Unicode Objects
+---------------
+
+.. sectionauthor:: Marc-Andre Lemburg <mal@lemburg.com>
+
+
+These are the basic Unicode object types used for the Unicode implementation in
+Python:
+
+.. % --- Unicode Type -------------------------------------------------------
+
+
+.. ctype:: Py_UNICODE
+
+   This type represents the storage type which is used by Python internally as
+   basis for holding Unicode ordinals.  Python's default builds use a 16-bit type
+   for :ctype:`Py_UNICODE` and store Unicode values internally as UCS2. It is also
+   possible to build a UCS4 version of Python (most recent Linux distributions come
+   with UCS4 builds of Python). These builds then use a 32-bit type for
+   :ctype:`Py_UNICODE` and store Unicode data internally as UCS4. On platforms
+   where :ctype:`wchar_t` is available and compatible with the chosen Python
+   Unicode build variant, :ctype:`Py_UNICODE` is a typedef alias for
+   :ctype:`wchar_t` to enhance native platform compatibility. On all other
+   platforms, :ctype:`Py_UNICODE` is a typedef alias for either :ctype:`unsigned
+   short` (UCS2) or :ctype:`unsigned long` (UCS4).
+
+Note that UCS2 and UCS4 Python builds are not binary compatible. Please keep
+this in mind when writing extensions or interfaces.
+
+
+.. ctype:: PyUnicodeObject
+
+   This subtype of :ctype:`PyObject` represents a Python Unicode object.
+
+
+.. cvar:: PyTypeObject PyUnicode_Type
+
+   This instance of :ctype:`PyTypeObject` represents the Python Unicode type.  It
+   is exposed to Python code as ``unicode`` and ``types.UnicodeType``.
+
+The following APIs are really C macros and can be used to do fast checks and to
+access internal read-only data of Unicode objects:
+
+
+.. cfunction:: int PyUnicode_Check(PyObject *o)
+
+   Return true if the object *o* is a Unicode object or an instance of a Unicode
+   subtype.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyUnicode_CheckExact(PyObject *o)
+
+   Return true if the object *o* is a Unicode object, but not an instance of a
+   subtype.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: Py_ssize_t PyUnicode_GET_SIZE(PyObject *o)
+
+   Return the size of the object.  *o* has to be a :ctype:`PyUnicodeObject` (not
+   checked).
+
+
+.. cfunction:: Py_ssize_t PyUnicode_GET_DATA_SIZE(PyObject *o)
+
+   Return the size of the object's internal buffer in bytes.  *o* has to be a
+   :ctype:`PyUnicodeObject` (not checked).
+
+
+.. cfunction:: Py_UNICODE* PyUnicode_AS_UNICODE(PyObject *o)
+
+   Return a pointer to the internal :ctype:`Py_UNICODE` buffer of the object.  *o*
+   has to be a :ctype:`PyUnicodeObject` (not checked).
+
+
+.. cfunction:: const char* PyUnicode_AS_DATA(PyObject *o)
+
+   Return a pointer to the internal buffer of the object. *o* has to be a
+   :ctype:`PyUnicodeObject` (not checked).
+
+Unicode provides many different character properties. The most often needed ones
+are available through these macros which are mapped to C functions depending on
+the Python configuration.
+
+.. % --- Unicode character properties ---------------------------------------
+
+
+.. cfunction:: int Py_UNICODE_ISSPACE(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a whitespace character.
+
+
+.. cfunction:: int Py_UNICODE_ISLOWER(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a lowercase character.
+
+
+.. cfunction:: int Py_UNICODE_ISUPPER(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is an uppercase character.
+
+
+.. cfunction:: int Py_UNICODE_ISTITLE(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a titlecase character.
+
+
+.. cfunction:: int Py_UNICODE_ISLINEBREAK(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a linebreak character.
+
+
+.. cfunction:: int Py_UNICODE_ISDECIMAL(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a decimal character.
+
+
+.. cfunction:: int Py_UNICODE_ISDIGIT(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a digit character.
+
+
+.. cfunction:: int Py_UNICODE_ISNUMERIC(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is a numeric character.
+
+
+.. cfunction:: int Py_UNICODE_ISALPHA(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is an alphabetic character.
+
+
+.. cfunction:: int Py_UNICODE_ISALNUM(Py_UNICODE ch)
+
+   Return 1 or 0 depending on whether *ch* is an alphanumeric character.
+
+These APIs can be used for fast direct character conversions:
+
+
+.. cfunction:: Py_UNICODE Py_UNICODE_TOLOWER(Py_UNICODE ch)
+
+   Return the character *ch* converted to lower case.
+
+
+.. cfunction:: Py_UNICODE Py_UNICODE_TOUPPER(Py_UNICODE ch)
+
+   Return the character *ch* converted to upper case.
+
+
+.. cfunction:: Py_UNICODE Py_UNICODE_TOTITLE(Py_UNICODE ch)
+
+   Return the character *ch* converted to title case.
+
+
+.. cfunction:: int Py_UNICODE_TODECIMAL(Py_UNICODE ch)
+
+   Return the character *ch* converted to a decimal positive integer.  Return
+   ``-1`` if this is not possible.  This macro does not raise exceptions.
+
+
+.. cfunction:: int Py_UNICODE_TODIGIT(Py_UNICODE ch)
+
+   Return the character *ch* converted to a single digit integer. Return ``-1`` if
+   this is not possible.  This macro does not raise exceptions.
+
+
+.. cfunction:: double Py_UNICODE_TONUMERIC(Py_UNICODE ch)
+
+   Return the character *ch* converted to a double. Return ``-1.0`` if this is not
+   possible.  This macro does not raise exceptions.
+
+To create Unicode objects and access their basic sequence properties, use these
+APIs:
+
+.. % --- Plain Py_UNICODE ---------------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_FromUnicode(const Py_UNICODE *u, Py_ssize_t size)
+
+   Create a Unicode Object from the Py_UNICODE buffer *u* of the given size. *u*
+   may be *NULL* which causes the contents to be undefined. It is the user's
+   responsibility to fill in the needed data.  The buffer is copied into the new
+   object. If the buffer is not *NULL*, the return value might be a shared object.
+   Therefore, modification of the resulting Unicode object is only allowed when *u*
+   is *NULL*.
+
+
+.. cfunction:: PyObject* PyUnicode_FromStringAndSize(const char *u, Py_ssize_t size)
+
+   Create a Unicode Object from the char buffer *u*.  The bytes will be interpreted
+   as being UTF-8 encoded.  *u* may also be *NULL* which
+   causes the contents to be undefined. It is the user's responsibility to fill in
+   the needed data.  The buffer is copied into the new object. If the buffer is not
+   *NULL*, the return value might be a shared object. Therefore, modification of
+   the resulting Unicode object is only allowed when *u* is *NULL*.
+
+   .. versionadded:: 3.0
+
+
+.. cfunction:: PyObject *PyUnicode_FromString(const char *u)
+
+   Create a Unicode object from an UTF-8 encoded null-terminated char buffer
+   *u*.
+
+   .. versionadded:: 3.0
+
+
+.. cfunction:: PyObject* PyUnicode_FromFormat(const char *format, ...)
+
+   Take a C :cfunc:`printf`\ -style *format* string and a variable number of
+   arguments, calculate the size of the resulting Python unicode string and return
+   a string with the values formatted into it.  The variable arguments must be C
+   types and must correspond exactly to the format characters in the *format*
+   string.  The following format characters are allowed:
+
+   .. % The descriptions for %zd and %zu are wrong, but the truth is complicated
+   .. % because not all compilers support the %z width modifier -- we fake it
+   .. % when necessary via interpolating PY_FORMAT_SIZE_T.
+
+   +-------------------+---------------------+--------------------------------+
+   | Format Characters | Type                | Comment                        |
+   +===================+=====================+================================+
+   | :attr:`%%`        | *n/a*               | The literal % character.       |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%c`        | int                 | A single character,            |
+   |                   |                     | represented as an C int.       |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%d`        | int                 | Exactly equivalent to          |
+   |                   |                     | ``printf("%d")``.              |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%u`        | unsigned int        | Exactly equivalent to          |
+   |                   |                     | ``printf("%u")``.              |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%ld`       | long                | Exactly equivalent to          |
+   |                   |                     | ``printf("%ld")``.             |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%lu`       | unsigned long       | Exactly equivalent to          |
+   |                   |                     | ``printf("%lu")``.             |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%zd`       | Py_ssize_t          | Exactly equivalent to          |
+   |                   |                     | ``printf("%zd")``.             |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%zu`       | size_t              | Exactly equivalent to          |
+   |                   |                     | ``printf("%zu")``.             |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%i`        | int                 | Exactly equivalent to          |
+   |                   |                     | ``printf("%i")``.              |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%x`        | int                 | Exactly equivalent to          |
+   |                   |                     | ``printf("%x")``.              |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%s`        | char\*              | A null-terminated C character  |
+   |                   |                     | array.                         |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%p`        | void\*              | The hex representation of a C  |
+   |                   |                     | pointer. Mostly equivalent to  |
+   |                   |                     | ``printf("%p")`` except that   |
+   |                   |                     | it is guaranteed to start with |
+   |                   |                     | the literal ``0x`` regardless  |
+   |                   |                     | of what the platform's         |
+   |                   |                     | ``printf`` yields.             |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%U`        | PyObject\*          | A unicode object.              |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%V`        | PyObject\*, char \* | A unicode object (which may be |
+   |                   |                     | *NULL*) and a null-terminated  |
+   |                   |                     | C character array as a second  |
+   |                   |                     | parameter (which will be used, |
+   |                   |                     | if the first parameter is      |
+   |                   |                     | *NULL*).                       |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%S`        | PyObject\*          | The result of calling          |
+   |                   |                     | :func:`PyObject_Unicode`.      |
+   +-------------------+---------------------+--------------------------------+
+   | :attr:`%R`        | PyObject\*          | The result of calling          |
+   |                   |                     | :func:`PyObject_Repr`.         |
+   +-------------------+---------------------+--------------------------------+
+
+   An unrecognized format character causes all the rest of the format string to be
+   copied as-is to the result string, and any extra arguments discarded.
+
+   .. versionadded:: 3.0
+
+
+.. cfunction:: PyObject* PyUnicode_FromFormatV(const char *format, va_list vargs)
+
+   Identical to :func:`PyUnicode_FromFormat` except that it takes exactly two
+   arguments.
+
+   .. versionadded:: 3.0
+
+
+.. cfunction:: Py_UNICODE* PyUnicode_AsUnicode(PyObject *unicode)
+
+   Return a read-only pointer to the Unicode object's internal :ctype:`Py_UNICODE`
+   buffer, *NULL* if *unicode* is not a Unicode object.
+
+
+.. cfunction:: Py_ssize_t PyUnicode_GetSize(PyObject *unicode)
+
+   Return the length of the Unicode object.
+
+
+.. cfunction:: PyObject* PyUnicode_FromEncodedObject(PyObject *obj, const char *encoding, const char *errors)
+
+   Coerce an encoded object *obj* to an Unicode object and return a reference with
+   incremented refcount.
+
+   String and other char buffer compatible objects are decoded according to the
+   given encoding and using the error handling defined by errors.  Both can be
+   *NULL* to have the interface use the default values (see the next section for
+   details).
+
+   All other objects, including Unicode objects, cause a :exc:`TypeError` to be
+   set.
+
+   The API returns *NULL* if there was an error.  The caller is responsible for
+   decref'ing the returned objects.
+
+
+.. cfunction:: PyObject* PyUnicode_FromObject(PyObject *obj)
+
+   Shortcut for ``PyUnicode_FromEncodedObject(obj, NULL, "strict")`` which is used
+   throughout the interpreter whenever coercion to Unicode is needed.
+
+If the platform supports :ctype:`wchar_t` and provides a header file wchar.h,
+Python can interface directly to this type using the following functions.
+Support is optimized if Python's own :ctype:`Py_UNICODE` type is identical to
+the system's :ctype:`wchar_t`.
+
+.. % --- wchar_t support for platforms which support it ---------------------
+
+
+.. cfunction:: PyObject* PyUnicode_FromWideChar(const wchar_t *w, Py_ssize_t size)
+
+   Create a Unicode object from the :ctype:`wchar_t` buffer *w* of the given size.
+   Return *NULL* on failure.
+
+
+.. cfunction:: Py_ssize_t PyUnicode_AsWideChar(PyUnicodeObject *unicode, wchar_t *w, Py_ssize_t size)
+
+   Copy the Unicode object contents into the :ctype:`wchar_t` buffer *w*.  At most
+   *size* :ctype:`wchar_t` characters are copied (excluding a possibly trailing
+   0-termination character).  Return the number of :ctype:`wchar_t` characters
+   copied or -1 in case of an error.  Note that the resulting :ctype:`wchar_t`
+   string may or may not be 0-terminated.  It is the responsibility of the caller
+   to make sure that the :ctype:`wchar_t` string is 0-terminated in case this is
+   required by the application.
+
+
+.. _builtincodecs:
+
+Built-in Codecs
+^^^^^^^^^^^^^^^
+
+Python provides a set of builtin codecs which are written in C for speed. All of
+these codecs are directly usable via the following functions.
+
+Many of the following APIs take two arguments encoding and errors. These
+parameters encoding and errors have the same semantics as the ones of the
+builtin unicode() Unicode object constructor.
+
+Setting encoding to *NULL* causes the default encoding to be used which is
+ASCII.  The file system calls should use :cdata:`Py_FileSystemDefaultEncoding`
+as the encoding for file names. This variable should be treated as read-only: On
+some systems, it will be a pointer to a static string, on others, it will change
+at run-time (such as when the application invokes setlocale).
+
+Error handling is set by errors which may also be set to *NULL* meaning to use
+the default handling defined for the codec.  Default error handling for all
+builtin codecs is "strict" (:exc:`ValueError` is raised).
+
+The codecs all use a similar interface.  Only deviation from the following
+generic ones are documented for simplicity.
+
+These are the generic codec APIs:
+
+.. % --- Generic Codecs -----------------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_Decode(const char *s, Py_ssize_t size, const char *encoding, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the encoded string *s*.
+   *encoding* and *errors* have the same meaning as the parameters of the same name
+   in the :func:`unicode` builtin function.  The codec to be used is looked up
+   using the Python codec registry.  Return *NULL* if an exception was raised by
+   the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_Encode(const Py_UNICODE *s, Py_ssize_t size, const char *encoding, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size and return a Python
+   string object.  *encoding* and *errors* have the same meaning as the parameters
+   of the same name in the Unicode :meth:`encode` method.  The codec to be used is
+   looked up using the Python codec registry.  Return *NULL* if an exception was
+   raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsEncodedString(PyObject *unicode, const char *encoding, const char *errors)
+
+   Encode a Unicode object and return the result as Python string object.
+   *encoding* and *errors* have the same meaning as the parameters of the same name
+   in the Unicode :meth:`encode` method. The codec to be used is looked up using
+   the Python codec registry. Return *NULL* if an exception was raised by the
+   codec.
+
+These are the UTF-8 codec APIs:
+
+.. % --- UTF-8 Codecs -------------------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeUTF8(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the UTF-8 encoded string
+   *s*. Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeUTF8Stateful(const char *s, Py_ssize_t size, const char *errors, Py_ssize_t *consumed)
+
+   If *consumed* is *NULL*, behave like :cfunc:`PyUnicode_DecodeUTF8`. If
+   *consumed* is not *NULL*, trailing incomplete UTF-8 byte sequences will not be
+   treated as an error. Those bytes will not be decoded and the number of bytes
+   that have been decoded will be stored in *consumed*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeUTF8(const Py_UNICODE *s, Py_ssize_t size, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using UTF-8 and return a
+   Python string object.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsUTF8String(PyObject *unicode)
+
+   Encode a Unicode objects using UTF-8 and return the result as Python string
+   object.  Error handling is "strict".  Return *NULL* if an exception was raised
+   by the codec.
+
+These are the UTF-16 codec APIs:
+
+.. % --- UTF-16 Codecs ------------------------------------------------------ */
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeUTF16(const char *s, Py_ssize_t size, const char *errors, int *byteorder)
+
+   Decode *length* bytes from a UTF-16 encoded buffer string and return the
+   corresponding Unicode object.  *errors* (if non-*NULL*) defines the error
+   handling. It defaults to "strict".
+
+   If *byteorder* is non-*NULL*, the decoder starts decoding using the given byte
+   order::
+
+      *byteorder == -1: little endian
+      *byteorder == 0:  native order
+      *byteorder == 1:  big endian
+
+   and then switches if the first two bytes of the input data are a byte order mark
+   (BOM) and the specified byte order is native order.  This BOM is not copied into
+   the resulting Unicode string.  After completion, *\*byteorder* is set to the
+   current byte order at the.
+
+   If *byteorder* is *NULL*, the codec starts in native order mode.
+
+   Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeUTF16Stateful(const char *s, Py_ssize_t size, const char *errors, int *byteorder, Py_ssize_t *consumed)
+
+   If *consumed* is *NULL*, behave like :cfunc:`PyUnicode_DecodeUTF16`. If
+   *consumed* is not *NULL*, :cfunc:`PyUnicode_DecodeUTF16Stateful` will not treat
+   trailing incomplete UTF-16 byte sequences (such as an odd number of bytes or a
+   split surrogate pair) as an error. Those bytes will not be decoded and the
+   number of bytes that have been decoded will be stored in *consumed*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeUTF16(const Py_UNICODE *s, Py_ssize_t size, const char *errors, int byteorder)
+
+   Return a Python string object holding the UTF-16 encoded value of the Unicode
+   data in *s*.  If *byteorder* is not ``0``, output is written according to the
+   following byte order::
+
+      byteorder == -1: little endian
+      byteorder == 0:  native byte order (writes a BOM mark)
+      byteorder == 1:  big endian
+
+   If byteorder is ``0``, the output string will always start with the Unicode BOM
+   mark (U+FEFF). In the other two modes, no BOM mark is prepended.
+
+   If *Py_UNICODE_WIDE* is defined, a single :ctype:`Py_UNICODE` value may get
+   represented as a surrogate pair. If it is not defined, each :ctype:`Py_UNICODE`
+   values is interpreted as an UCS-2 character.
+
+   Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsUTF16String(PyObject *unicode)
+
+   Return a Python string using the UTF-16 encoding in native byte order. The
+   string always starts with a BOM mark.  Error handling is "strict".  Return
+   *NULL* if an exception was raised by the codec.
+
+These are the "Unicode Escape" codec APIs:
+
+.. % --- Unicode-Escape Codecs ----------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeUnicodeEscape(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the Unicode-Escape encoded
+   string *s*.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeUnicodeEscape(const Py_UNICODE *s, Py_ssize_t size)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using Unicode-Escape and
+   return a Python string object.  Return *NULL* if an exception was raised by the
+   codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsUnicodeEscapeString(PyObject *unicode)
+
+   Encode a Unicode objects using Unicode-Escape and return the result as Python
+   string object.  Error handling is "strict". Return *NULL* if an exception was
+   raised by the codec.
+
+These are the "Raw Unicode Escape" codec APIs:
+
+.. % --- Raw-Unicode-Escape Codecs ------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeRawUnicodeEscape(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the Raw-Unicode-Escape
+   encoded string *s*.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeRawUnicodeEscape(const Py_UNICODE *s, Py_ssize_t size, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using Raw-Unicode-Escape
+   and return a Python string object.  Return *NULL* if an exception was raised by
+   the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsRawUnicodeEscapeString(PyObject *unicode)
+
+   Encode a Unicode objects using Raw-Unicode-Escape and return the result as
+   Python string object. Error handling is "strict". Return *NULL* if an exception
+   was raised by the codec.
+
+These are the Latin-1 codec APIs: Latin-1 corresponds to the first 256 Unicode
+ordinals and only these are accepted by the codecs during encoding.
+
+.. % --- Latin-1 Codecs -----------------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeLatin1(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the Latin-1 encoded string
+   *s*.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeLatin1(const Py_UNICODE *s, Py_ssize_t size, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using Latin-1 and return
+   a Python string object.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsLatin1String(PyObject *unicode)
+
+   Encode a Unicode objects using Latin-1 and return the result as Python string
+   object.  Error handling is "strict".  Return *NULL* if an exception was raised
+   by the codec.
+
+These are the ASCII codec APIs.  Only 7-bit ASCII data is accepted. All other
+codes generate errors.
+
+.. % --- ASCII Codecs -------------------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeASCII(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the ASCII encoded string
+   *s*.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeASCII(const Py_UNICODE *s, Py_ssize_t size, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using ASCII and return a
+   Python string object.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsASCIIString(PyObject *unicode)
+
+   Encode a Unicode objects using ASCII and return the result as Python string
+   object.  Error handling is "strict".  Return *NULL* if an exception was raised
+   by the codec.
+
+These are the mapping codec APIs:
+
+.. % --- Character Map Codecs -----------------------------------------------
+
+This codec is special in that it can be used to implement many different codecs
+(and this is in fact what was done to obtain most of the standard codecs
+included in the :mod:`encodings` package). The codec uses mapping to encode and
+decode characters.
+
+Decoding mappings must map single string characters to single Unicode
+characters, integers (which are then interpreted as Unicode ordinals) or None
+(meaning "undefined mapping" and causing an error).
+
+Encoding mappings must map single Unicode characters to single string
+characters, integers (which are then interpreted as Latin-1 ordinals) or None
+(meaning "undefined mapping" and causing an error).
+
+The mapping objects provided must only support the __getitem__ mapping
+interface.
+
+If a character lookup fails with a LookupError, the character is copied as-is
+meaning that its ordinal value will be interpreted as Unicode or Latin-1 ordinal
+resp. Because of this, mappings only need to contain those mappings which map
+characters to different code points.
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeCharmap(const char *s, Py_ssize_t size, PyObject *mapping, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the encoded string *s* using
+   the given *mapping* object.  Return *NULL* if an exception was raised by the
+   codec. If *mapping* is *NULL* latin-1 decoding will be done. Else it can be a
+   dictionary mapping byte or a unicode string, which is treated as a lookup table.
+   Byte values greater that the length of the string and U+FFFE "characters" are
+   treated as "undefined mapping".
+
+   .. versionchanged:: 2.4
+      Allowed unicode string as mapping argument.
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeCharmap(const Py_UNICODE *s, Py_ssize_t size, PyObject *mapping, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using the given
+   *mapping* object and return a Python string object. Return *NULL* if an
+   exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsCharmapString(PyObject *unicode, PyObject *mapping)
+
+   Encode a Unicode objects using the given *mapping* object and return the result
+   as Python string object.  Error handling is "strict".  Return *NULL* if an
+   exception was raised by the codec.
+
+The following codec API is special in that maps Unicode to Unicode.
+
+
+.. cfunction:: PyObject* PyUnicode_TranslateCharmap(const Py_UNICODE *s, Py_ssize_t size, PyObject *table, const char *errors)
+
+   Translate a :ctype:`Py_UNICODE` buffer of the given length by applying a
+   character mapping *table* to it and return the resulting Unicode object.  Return
+   *NULL* when an exception was raised by the codec.
+
+   The *mapping* table must map Unicode ordinal integers to Unicode ordinal
+   integers or None (causing deletion of the character).
+
+   Mapping tables need only provide the :meth:`__getitem__` interface; dictionaries
+   and sequences work well.  Unmapped character ordinals (ones which cause a
+   :exc:`LookupError`) are left untouched and are copied as-is.
+
+These are the MBCS codec APIs. They are currently only available on Windows and
+use the Win32 MBCS converters to implement the conversions.  Note that MBCS (or
+DBCS) is a class of encodings, not just one.  The target encoding is defined by
+the user settings on the machine running the codec.
+
+.. % --- MBCS codecs for Windows --------------------------------------------
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeMBCS(const char *s, Py_ssize_t size, const char *errors)
+
+   Create a Unicode object by decoding *size* bytes of the MBCS encoded string *s*.
+   Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_DecodeMBCSStateful(const char *s, int size, const char *errors, int *consumed)
+
+   If *consumed* is *NULL*, behave like :cfunc:`PyUnicode_DecodeMBCS`. If
+   *consumed* is not *NULL*, :cfunc:`PyUnicode_DecodeMBCSStateful` will not decode
+   trailing lead byte and the number of bytes that have been decoded will be stored
+   in *consumed*.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: PyObject* PyUnicode_EncodeMBCS(const Py_UNICODE *s, Py_ssize_t size, const char *errors)
+
+   Encode the :ctype:`Py_UNICODE` buffer of the given size using MBCS and return a
+   Python string object.  Return *NULL* if an exception was raised by the codec.
+
+
+.. cfunction:: PyObject* PyUnicode_AsMBCSString(PyObject *unicode)
+
+   Encode a Unicode objects using MBCS and return the result as Python string
+   object.  Error handling is "strict".  Return *NULL* if an exception was raised
+   by the codec.
+
+.. % --- Methods & Slots ----------------------------------------------------
+
+
+.. _unicodemethodsandslots:
+
+Methods and Slot Functions
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The following APIs are capable of handling Unicode objects and strings on input
+(we refer to them as strings in the descriptions) and return Unicode objects or
+integers as appropriate.
+
+They all return *NULL* or ``-1`` if an exception occurs.
+
+
+.. cfunction:: PyObject* PyUnicode_Concat(PyObject *left, PyObject *right)
+
+   Concat two strings giving a new Unicode string.
+
+
+.. cfunction:: PyObject* PyUnicode_Split(PyObject *s, PyObject *sep, Py_ssize_t maxsplit)
+
+   Split a string giving a list of Unicode strings.  If sep is *NULL*, splitting
+   will be done at all whitespace substrings.  Otherwise, splits occur at the given
+   separator.  At most *maxsplit* splits will be done.  If negative, no limit is
+   set.  Separators are not included in the resulting list.
+
+
+.. cfunction:: PyObject* PyUnicode_Splitlines(PyObject *s, int keepend)
+
+   Split a Unicode string at line breaks, returning a list of Unicode strings.
+   CRLF is considered to be one line break.  If *keepend* is 0, the Line break
+   characters are not included in the resulting strings.
+
+
+.. cfunction:: PyObject* PyUnicode_Translate(PyObject *str, PyObject *table, const char *errors)
+
+   Translate a string by applying a character mapping table to it and return the
+   resulting Unicode object.
+
+   The mapping table must map Unicode ordinal integers to Unicode ordinal integers
+   or None (causing deletion of the character).
+
+   Mapping tables need only provide the :meth:`__getitem__` interface; dictionaries
+   and sequences work well.  Unmapped character ordinals (ones which cause a
+   :exc:`LookupError`) are left untouched and are copied as-is.
+
+   *errors* has the usual meaning for codecs. It may be *NULL* which indicates to
+   use the default error handling.
+
+
+.. cfunction:: PyObject* PyUnicode_Join(PyObject *separator, PyObject *seq)
+
+   Join a sequence of strings using the given separator and return the resulting
+   Unicode string.
+
+
+.. cfunction:: int PyUnicode_Tailmatch(PyObject *str, PyObject *substr, Py_ssize_t start, Py_ssize_t end, int direction)
+
+   Return 1 if *substr* matches *str*[*start*:*end*] at the given tail end
+   (*direction* == -1 means to do a prefix match, *direction* == 1 a suffix match),
+   0 otherwise. Return ``-1`` if an error occurred.
+
+
+.. cfunction:: Py_ssize_t PyUnicode_Find(PyObject *str, PyObject *substr, Py_ssize_t start, Py_ssize_t end, int direction)
+
+   Return the first position of *substr* in *str*[*start*:*end*] using the given
+   *direction* (*direction* == 1 means to do a forward search, *direction* == -1 a
+   backward search).  The return value is the index of the first match; a value of
+   ``-1`` indicates that no match was found, and ``-2`` indicates that an error
+   occurred and an exception has been set.
+
+
+.. cfunction:: Py_ssize_t PyUnicode_Count(PyObject *str, PyObject *substr, Py_ssize_t start, Py_ssize_t end)
+
+   Return the number of non-overlapping occurrences of *substr* in
+   ``str[start:end]``.  Return ``-1`` if an error occurred.
+
+
+.. cfunction:: PyObject* PyUnicode_Replace(PyObject *str, PyObject *substr, PyObject *replstr, Py_ssize_t maxcount)
+
+   Replace at most *maxcount* occurrences of *substr* in *str* with *replstr* and
+   return the resulting Unicode object. *maxcount* == -1 means replace all
+   occurrences.
+
+
+.. cfunction:: int PyUnicode_Compare(PyObject *left, PyObject *right)
+
+   Compare two strings and return -1, 0, 1 for less than, equal, and greater than,
+   respectively.
+
+
+.. cfunction:: int PyUnicode_RichCompare(PyObject *left,  PyObject *right,  int op)
+
+   Rich compare two unicode strings and return one of the following:
+
+   * ``NULL`` in case an exception was raised
+   * :const:`Py_True` or :const:`Py_False` for successful comparisons
+   * :const:`Py_NotImplemented` in case the type combination is unknown
+
+   Note that :const:`Py_EQ` and :const:`Py_NE` comparisons can cause a
+   :exc:`UnicodeWarning` in case the conversion of the arguments to Unicode fails
+   with a :exc:`UnicodeDecodeError`.
+
+   Possible values for *op* are :const:`Py_GT`, :const:`Py_GE`, :const:`Py_EQ`,
+   :const:`Py_NE`, :const:`Py_LT`, and :const:`Py_LE`.
+
+
+.. cfunction:: PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
+
+   Return a new string object from *format* and *args*; this is analogous to
+   ``format % args``.  The *args* argument must be a tuple.
+
+
+.. cfunction:: int PyUnicode_Contains(PyObject *container, PyObject *element)
+
+   Check whether *element* is contained in *container* and return true or false
+   accordingly.
+
+   *element* has to coerce to a one element Unicode string. ``-1`` is returned if
+   there was an error.
+
+
+.. cfunction:: void PyUnicode_InternInPlace(PyObject **string)
+
+   Intern the argument *\*string* in place.  The argument must be the address of a
+   pointer variable pointing to a Python unicode string object.  If there is an
+   existing interned string that is the same as *\*string*, it sets *\*string* to
+   it (decrementing the reference count of the old string object and incrementing
+   the reference count of the interned string object), otherwise it leaves
+   *\*string* alone and interns it (incrementing its reference count).
+   (Clarification: even though there is a lot of talk about reference counts, think
+   of this function as reference-count-neutral; you own the object after the call
+   if and only if you owned it before the call.)
+
+
+.. cfunction:: PyObject* PyUnicode_InternFromString(const char *v)
+
+   A combination of :cfunc:`PyUnicode_FromString` and
+   :cfunc:`PyUnicode_InternInPlace`, returning either a new unicode string object
+   that has been interned, or a new ("owned") reference to an earlier interned
+   string object with the same value.
+
+
+.. _bufferobjects:
+
+Buffer Objects
+--------------
+
+.. sectionauthor:: Greg Stein <gstein@lyra.org>
+
+
+.. index::
+   object: buffer
+   single: buffer interface
+
+Python objects implemented in C can export a group of functions called the
+"buffer interface."  These functions can be used by an object to expose its data
+in a raw, byte-oriented format. Clients of the object can use the buffer
+interface to access the object data directly, without needing to copy it first.
+
+Two examples of objects that support the buffer interface are strings and
+arrays. The string object exposes the character contents in the buffer
+interface's byte-oriented form. An array can also expose its contents, but it
+should be noted that array elements may be multi-byte values.
+
+An example user of the buffer interface is the file object's :meth:`write`
+method. Any object that can export a series of bytes through the buffer
+interface can be written to a file. There are a number of format codes to
+:cfunc:`PyArg_ParseTuple` that operate against an object's buffer interface,
+returning data from the target object.
+
+.. index:: single: PyBufferProcs
+
+More information on the buffer interface is provided in the section 
+:ref:`buffer-structs`, under the description for :ctype:`PyBufferProcs`.
+
+A "buffer object" is defined in the :file:`bufferobject.h` header (included by
+:file:`Python.h`). These objects look very similar to string objects at the
+Python programming level: they support slicing, indexing, concatenation, and
+some other standard string operations. However, their data can come from one of
+two sources: from a block of memory, or from another object which exports the
+buffer interface.
+
+Buffer objects are useful as a way to expose the data from another object's
+buffer interface to the Python programmer. They can also be used as a zero-copy
+slicing mechanism. Using their ability to reference a block of memory, it is
+possible to expose any data to the Python programmer quite easily. The memory
+could be a large, constant array in a C extension, it could be a raw block of
+memory for manipulation before passing to an operating system library, or it
+could be used to pass around structured data in its native, in-memory format.
+
+
+.. ctype:: PyBufferObject
+
+   This subtype of :ctype:`PyObject` represents a buffer object.
+
+
+.. cvar:: PyTypeObject PyBuffer_Type
+
+   .. index:: single: BufferType (in module types)
+
+   The instance of :ctype:`PyTypeObject` which represents the Python buffer type;
+   it is the same object as ``buffer`` and  ``types.BufferType`` in the Python
+   layer. .
+
+
+.. cvar:: int Py_END_OF_BUFFER
+
+   This constant may be passed as the *size* parameter to
+   :cfunc:`PyBuffer_FromObject` or :cfunc:`PyBuffer_FromReadWriteObject`.  It
+   indicates that the new :ctype:`PyBufferObject` should refer to *base* object
+   from the specified *offset* to the end of its exported buffer.  Using this
+   enables the caller to avoid querying the *base* object for its length.
+
+
+.. cfunction:: int PyBuffer_Check(PyObject *p)
+
+   Return true if the argument has type :cdata:`PyBuffer_Type`.
+
+
+.. cfunction:: PyObject* PyBuffer_FromObject(PyObject *base, Py_ssize_t offset, Py_ssize_t size)
+
+   Return a new read-only buffer object.  This raises :exc:`TypeError` if *base*
+   doesn't support the read-only buffer protocol or doesn't provide exactly one
+   buffer segment, or it raises :exc:`ValueError` if *offset* is less than zero.
+   The buffer will hold a reference to the *base* object, and the buffer's contents
+   will refer to the *base* object's buffer interface, starting as position
+   *offset* and extending for *size* bytes. If *size* is :const:`Py_END_OF_BUFFER`,
+   then the new buffer's contents extend to the length of the *base* object's
+   exported buffer data.
+
+
+.. cfunction:: PyObject* PyBuffer_FromReadWriteObject(PyObject *base, Py_ssize_t offset, Py_ssize_t size)
+
+   Return a new writable buffer object.  Parameters and exceptions are similar to
+   those for :cfunc:`PyBuffer_FromObject`.  If the *base* object does not export
+   the writeable buffer protocol, then :exc:`TypeError` is raised.
+
+
+.. cfunction:: PyObject* PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
+
+   Return a new read-only buffer object that reads from a specified location in
+   memory, with a specified size.  The caller is responsible for ensuring that the
+   memory buffer, passed in as *ptr*, is not deallocated while the returned buffer
+   object exists.  Raises :exc:`ValueError` if *size* is less than zero.  Note that
+   :const:`Py_END_OF_BUFFER` may *not* be passed for the *size* parameter;
+   :exc:`ValueError` will be raised in that case.
+
+
+.. cfunction:: PyObject* PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)
+
+   Similar to :cfunc:`PyBuffer_FromMemory`, but the returned buffer is writable.
+
+
+.. cfunction:: PyObject* PyBuffer_New(Py_ssize_t size)
+
+   Return a new writable buffer object that maintains its own memory buffer of
+   *size* bytes.  :exc:`ValueError` is returned if *size* is not zero or positive.
+   Note that the memory buffer (as returned by :cfunc:`PyObject_AsWriteBuffer`) is
+   not specifically aligned.
+
+
+.. _tupleobjects:
+
+Tuple Objects
+-------------
+
+.. index:: object: tuple
+
+
+.. ctype:: PyTupleObject
+
+   This subtype of :ctype:`PyObject` represents a Python tuple object.
+
+
+.. cvar:: PyTypeObject PyTuple_Type
+
+   .. index:: single: TupleType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python tuple type; it is
+   the same object as ``tuple`` and ``types.TupleType`` in the Python layer..
+
+
+.. cfunction:: int PyTuple_Check(PyObject *p)
+
+   Return true if *p* is a tuple object or an instance of a subtype of the tuple
+   type.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyTuple_CheckExact(PyObject *p)
+
+   Return true if *p* is a tuple object, but not an instance of a subtype of the
+   tuple type.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyTuple_New(Py_ssize_t len)
+
+   Return a new tuple object of size *len*, or *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyTuple_Pack(Py_ssize_t n, ...)
+
+   Return a new tuple object of size *n*, or *NULL* on failure. The tuple values
+   are initialized to the subsequent *n* C arguments pointing to Python objects.
+   ``PyTuple_Pack(2, a, b)`` is equivalent to ``Py_BuildValue("(OO)", a, b)``.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyTuple_Size(PyObject *p)
+
+   Take a pointer to a tuple object, and return the size of that tuple.
+
+
+.. cfunction:: int PyTuple_GET_SIZE(PyObject *p)
+
+   Return the size of the tuple *p*, which must be non-*NULL* and point to a tuple;
+   no error checking is performed.
+
+
+.. cfunction:: PyObject* PyTuple_GetItem(PyObject *p, Py_ssize_t pos)
+
+   Return the object at position *pos* in the tuple pointed to by *p*.  If *pos* is
+   out of bounds, return *NULL* and sets an :exc:`IndexError` exception.
+
+
+.. cfunction:: PyObject* PyTuple_GET_ITEM(PyObject *p, Py_ssize_t pos)
+
+   Like :cfunc:`PyTuple_GetItem`, but does no checking of its arguments.
+
+
+.. cfunction:: PyObject* PyTuple_GetSlice(PyObject *p, Py_ssize_t low, Py_ssize_t high)
+
+   Take a slice of the tuple pointed to by *p* from *low* to *high* and return it
+   as a new tuple.
+
+
+.. cfunction:: int PyTuple_SetItem(PyObject *p, Py_ssize_t pos, PyObject *o)
+
+   Insert a reference to object *o* at position *pos* of the tuple pointed to by
+   *p*. Return ``0`` on success.
+
+   .. note::
+
+      This function "steals" a reference to *o*.
+
+
+.. cfunction:: void PyTuple_SET_ITEM(PyObject *p, Py_ssize_t pos, PyObject *o)
+
+   Like :cfunc:`PyTuple_SetItem`, but does no error checking, and should *only* be
+   used to fill in brand new tuples.
+
+   .. note::
+
+      This function "steals" a reference to *o*.
+
+
+.. cfunction:: int _PyTuple_Resize(PyObject **p, Py_ssize_t newsize)
+
+   Can be used to resize a tuple.  *newsize* will be the new length of the tuple.
+   Because tuples are *supposed* to be immutable, this should only be used if there
+   is only one reference to the object.  Do *not* use this if the tuple may already
+   be known to some other part of the code.  The tuple will always grow or shrink
+   at the end.  Think of this as destroying the old tuple and creating a new one,
+   only more efficiently.  Returns ``0`` on success. Client code should never
+   assume that the resulting value of ``*p`` will be the same as before calling
+   this function. If the object referenced by ``*p`` is replaced, the original
+   ``*p`` is destroyed.  On failure, returns ``-1`` and sets ``*p`` to *NULL*, and
+   raises :exc:`MemoryError` or :exc:`SystemError`.
+
+   .. versionchanged:: 2.2
+      Removed unused third parameter, *last_is_sticky*.
+
+
+.. _listobjects:
+
+List Objects
+------------
+
+.. index:: object: list
+
+
+.. ctype:: PyListObject
+
+   This subtype of :ctype:`PyObject` represents a Python list object.
+
+
+.. cvar:: PyTypeObject PyList_Type
+
+   .. index:: single: ListType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python list type.  This is
+   the same object as ``list`` and ``types.ListType`` in the Python layer.
+
+
+.. cfunction:: int PyList_Check(PyObject *p)
+
+   Return true if *p* is a list object or an instance of a subtype of the list
+   type.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyList_CheckExact(PyObject *p)
+
+   Return true if *p* is a list object, but not an instance of a subtype of the
+   list type.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyList_New(Py_ssize_t len)
+
+   Return a new list of length *len* on success, or *NULL* on failure.
+
+   .. note::
+
+      If *length* is greater than zero, the returned list object's items are set to
+      ``NULL``.  Thus you cannot use abstract API functions such as
+      :cfunc:`PySequence_SetItem`  or expose the object to Python code before setting
+      all items to a real object with :cfunc:`PyList_SetItem`.
+
+
+.. cfunction:: Py_ssize_t PyList_Size(PyObject *list)
+
+   .. index:: builtin: len
+
+   Return the length of the list object in *list*; this is equivalent to
+   ``len(list)`` on a list object.
+
+
+.. cfunction:: Py_ssize_t PyList_GET_SIZE(PyObject *list)
+
+   Macro form of :cfunc:`PyList_Size` without error checking.
+
+
+.. cfunction:: PyObject* PyList_GetItem(PyObject *list, Py_ssize_t index)
+
+   Return the object at position *pos* in the list pointed to by *p*.  The position
+   must be positive, indexing from the end of the list is not supported.  If *pos*
+   is out of bounds, return *NULL* and set an :exc:`IndexError` exception.
+
+
+.. cfunction:: PyObject* PyList_GET_ITEM(PyObject *list, Py_ssize_t i)
+
+   Macro form of :cfunc:`PyList_GetItem` without error checking.
+
+
+.. cfunction:: int PyList_SetItem(PyObject *list, Py_ssize_t index, PyObject *item)
+
+   Set the item at index *index* in list to *item*.  Return ``0`` on success or
+   ``-1`` on failure.
+
+   .. note::
+
+      This function "steals" a reference to *item* and discards a reference to an item
+      already in the list at the affected position.
+
+
+.. cfunction:: void PyList_SET_ITEM(PyObject *list, Py_ssize_t i, PyObject *o)
+
+   Macro form of :cfunc:`PyList_SetItem` without error checking. This is normally
+   only used to fill in new lists where there is no previous content.
+
+   .. note::
+
+      This function "steals" a reference to *item*, and, unlike
+      :cfunc:`PyList_SetItem`, does *not* discard a reference to any item that it
+      being replaced; any reference in *list* at position *i* will be leaked.
+
+
+.. cfunction:: int PyList_Insert(PyObject *list, Py_ssize_t index, PyObject *item)
+
+   Insert the item *item* into list *list* in front of index *index*.  Return ``0``
+   if successful; return ``-1`` and set an exception if unsuccessful.  Analogous to
+   ``list.insert(index, item)``.
+
+
+.. cfunction:: int PyList_Append(PyObject *list, PyObject *item)
+
+   Append the object *item* at the end of list *list*. Return ``0`` if successful;
+   return ``-1`` and set an exception if unsuccessful.  Analogous to
+   ``list.append(item)``.
+
+
+.. cfunction:: PyObject* PyList_GetSlice(PyObject *list, Py_ssize_t low, Py_ssize_t high)
+
+   Return a list of the objects in *list* containing the objects *between* *low*
+   and *high*.  Return *NULL* and set an exception if unsuccessful. Analogous to
+   ``list[low:high]``.
+
+
+.. cfunction:: int PyList_SetSlice(PyObject *list, Py_ssize_t low, Py_ssize_t high, PyObject *itemlist)
+
+   Set the slice of *list* between *low* and *high* to the contents of *itemlist*.
+   Analogous to ``list[low:high] = itemlist``. The *itemlist* may be *NULL*,
+   indicating the assignment of an empty list (slice deletion). Return ``0`` on
+   success, ``-1`` on failure.
+
+
+.. cfunction:: int PyList_Sort(PyObject *list)
+
+   Sort the items of *list* in place.  Return ``0`` on success, ``-1`` on failure.
+   This is equivalent to ``list.sort()``.
+
+
+.. cfunction:: int PyList_Reverse(PyObject *list)
+
+   Reverse the items of *list* in place.  Return ``0`` on success, ``-1`` on
+   failure.  This is the equivalent of ``list.reverse()``.
+
+
+.. cfunction:: PyObject* PyList_AsTuple(PyObject *list)
+
+   .. index:: builtin: tuple
+
+   Return a new tuple object containing the contents of *list*; equivalent to
+   ``tuple(list)``.
+
+
+.. _mapobjects:
+
+Mapping Objects
+===============
+
+.. index:: object: mapping
+
+
+.. _dictobjects:
+
+Dictionary Objects
+------------------
+
+.. index:: object: dictionary
+
+
+.. ctype:: PyDictObject
+
+   This subtype of :ctype:`PyObject` represents a Python dictionary object.
+
+
+.. cvar:: PyTypeObject PyDict_Type
+
+   .. index::
+      single: DictType (in module types)
+      single: DictionaryType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python dictionary type.
+   This is exposed to Python programs as ``dict`` and ``types.DictType``.
+
+
+.. cfunction:: int PyDict_Check(PyObject *p)
+
+   Return true if *p* is a dict object or an instance of a subtype of the dict
+   type.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyDict_CheckExact(PyObject *p)
+
+   Return true if *p* is a dict object, but not an instance of a subtype of the
+   dict type.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyDict_New()
+
+   Return a new empty dictionary, or *NULL* on failure.
+
+
+.. cfunction:: PyObject* PyDictProxy_New(PyObject *dict)
+
+   Return a proxy object for a mapping which enforces read-only behavior.  This is
+   normally used to create a proxy to prevent modification of the dictionary for
+   non-dynamic class types.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: void PyDict_Clear(PyObject *p)
+
+   Empty an existing dictionary of all key-value pairs.
+
+
+.. cfunction:: int PyDict_Contains(PyObject *p, PyObject *key)
+
+   Determine if dictionary *p* contains *key*.  If an item in *p* is matches *key*,
+   return ``1``, otherwise return ``0``.  On error, return ``-1``.  This is
+   equivalent to the Python expression ``key in p``.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyDict_Copy(PyObject *p)
+
+   Return a new dictionary that contains the same key-value pairs as *p*.
+
+   .. versionadded:: 1.6
+
+
+.. cfunction:: int PyDict_SetItem(PyObject *p, PyObject *key, PyObject *val)
+
+   Insert *value* into the dictionary *p* with a key of *key*.  *key* must be
+   hashable; if it isn't, :exc:`TypeError` will be raised. Return ``0`` on success
+   or ``-1`` on failure.
+
+
+.. cfunction:: int PyDict_SetItemString(PyObject *p, const char *key, PyObject *val)
+
+   .. index:: single: PyString_FromString()
+
+   Insert *value* into the dictionary *p* using *key* as a key. *key* should be a
+   :ctype:`char\*`.  The key object is created using ``PyString_FromString(key)``.
+   Return ``0`` on success or ``-1`` on failure.
+
+
+.. cfunction:: int PyDict_DelItem(PyObject *p, PyObject *key)
+
+   Remove the entry in dictionary *p* with key *key*. *key* must be hashable; if it
+   isn't, :exc:`TypeError` is raised.  Return ``0`` on success or ``-1`` on
+   failure.
+
+
+.. cfunction:: int PyDict_DelItemString(PyObject *p, char *key)
+
+   Remove the entry in dictionary *p* which has a key specified by the string
+   *key*.  Return ``0`` on success or ``-1`` on failure.
+
+
+.. cfunction:: PyObject* PyDict_GetItem(PyObject *p, PyObject *key)
+
+   Return the object from dictionary *p* which has a key *key*.  Return *NULL* if
+   the key *key* is not present, but *without* setting an exception.
+
+
+.. cfunction:: PyObject* PyDict_GetItemString(PyObject *p, const char *key)
+
+   This is the same as :cfunc:`PyDict_GetItem`, but *key* is specified as a
+   :ctype:`char\*`, rather than a :ctype:`PyObject\*`.
+
+
+.. cfunction:: PyObject* PyDict_Items(PyObject *p)
+
+   Return a :ctype:`PyListObject` containing all the items from the dictionary, as
+   in the dictionary method :meth:`dict.items`.
+
+
+.. cfunction:: PyObject* PyDict_Keys(PyObject *p)
+
+   Return a :ctype:`PyListObject` containing all the keys from the dictionary, as
+   in the dictionary method :meth:`dict.keys`.
+
+
+.. cfunction:: PyObject* PyDict_Values(PyObject *p)
+
+   Return a :ctype:`PyListObject` containing all the values from the dictionary
+   *p*, as in the dictionary method :meth:`dict.values`.
+
+
+.. cfunction:: Py_ssize_t PyDict_Size(PyObject *p)
+
+   .. index:: builtin: len
+
+   Return the number of items in the dictionary.  This is equivalent to ``len(p)``
+   on a dictionary.
+
+
+.. cfunction:: int PyDict_Next(PyObject *p, Py_ssize_t *ppos, PyObject **pkey, PyObject **pvalue)
+
+   Iterate over all key-value pairs in the dictionary *p*.  The :ctype:`int`
+   referred to by *ppos* must be initialized to ``0`` prior to the first call to
+   this function to start the iteration; the function returns true for each pair in
+   the dictionary, and false once all pairs have been reported.  The parameters
+   *pkey* and *pvalue* should either point to :ctype:`PyObject\*` variables that
+   will be filled in with each key and value, respectively, or may be *NULL*.  Any
+   references returned through them are borrowed.  *ppos* should not be altered
+   during iteration. Its value represents offsets within the internal dictionary
+   structure, and since the structure is sparse, the offsets are not consecutive.
+
+   For example::
+
+      PyObject *key, *value;
+      Py_ssize_t pos = 0;
+
+      while (PyDict_Next(self->dict, &pos, &key, &value)) {
+          /* do something interesting with the values... */
+          ...
+      }
+
+   The dictionary *p* should not be mutated during iteration.  It is safe (since
+   Python 2.1) to modify the values of the keys as you iterate over the dictionary,
+   but only so long as the set of keys does not change.  For example::
+
+      PyObject *key, *value;
+      Py_ssize_t pos = 0;
+
+      while (PyDict_Next(self->dict, &pos, &key, &value)) {
+          int i = PyInt_AS_LONG(value) + 1;
+          PyObject *o = PyInt_FromLong(i);
+          if (o == NULL)
+              return -1;
+          if (PyDict_SetItem(self->dict, key, o) < 0) {
+              Py_DECREF(o);
+              return -1;
+          }
+          Py_DECREF(o);
+      }
+
+
+.. cfunction:: int PyDict_Merge(PyObject *a, PyObject *b, int override)
+
+   Iterate over mapping object *b* adding key-value pairs to dictionary *a*. *b*
+   may be a dictionary, or any object supporting :func:`PyMapping_Keys` and
+   :func:`PyObject_GetItem`. If *override* is true, existing pairs in *a* will be
+   replaced if a matching key is found in *b*, otherwise pairs will only be added
+   if there is not a matching key in *a*. Return ``0`` on success or ``-1`` if an
+   exception was raised.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyDict_Update(PyObject *a, PyObject *b)
+
+   This is the same as ``PyDict_Merge(a, b, 1)`` in C, or ``a.update(b)`` in
+   Python.  Return ``0`` on success or ``-1`` if an exception was raised.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyDict_MergeFromSeq2(PyObject *a, PyObject *seq2, int override)
+
+   Update or merge into dictionary *a*, from the key-value pairs in *seq2*.  *seq2*
+   must be an iterable object producing iterable objects of length 2, viewed as
+   key-value pairs.  In case of duplicate keys, the last wins if *override* is
+   true, else the first wins. Return ``0`` on success or ``-1`` if an exception was
+   raised. Equivalent Python (except for the return value)::
+
+      def PyDict_MergeFromSeq2(a, seq2, override):
+          for key, value in seq2:
+              if override or key not in a:
+                  a[key] = value
+
+   .. versionadded:: 2.2
+
+
+.. _otherobjects:
+
+Other Objects
+=============
+
+
+.. _classobjects:
+
+Class Objects
+-------------
+
+.. index:: object: class
+
+Note that the class objects described here represent old-style classes, which
+will go away in Python 3. When creating new types for extension modules, you
+will want to work with type objects (section :ref:`typeobjects`).
+
+
+.. ctype:: PyClassObject
+
+   The C structure of the objects used to describe built-in classes.
+
+
+.. cvar:: PyObject* PyClass_Type
+
+   .. index:: single: ClassType (in module types)
+
+   This is the type object for class objects; it is the same object as
+   ``types.ClassType`` in the Python layer.
+
+
+.. cfunction:: int PyClass_Check(PyObject *o)
+
+   Return true if the object *o* is a class object, including instances of types
+   derived from the standard class object.  Return false in all other cases.
+
+
+.. cfunction:: int PyClass_IsSubclass(PyObject *klass, PyObject *base)
+
+   Return true if *klass* is a subclass of *base*. Return false in all other cases.
+
+
+.. _fileobjects:
+
+File Objects
+------------
+
+.. index:: object: file
+
+Python's built-in file objects are implemented entirely on the :ctype:`FILE\*`
+support from the C standard library.  This is an implementation detail and may
+change in future releases of Python.
+
+
+.. ctype:: PyFileObject
+
+   This subtype of :ctype:`PyObject` represents a Python file object.
+
+
+.. cvar:: PyTypeObject PyFile_Type
+
+   .. index:: single: FileType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python file type.  This is
+   exposed to Python programs as ``file`` and ``types.FileType``.
+
+
+.. cfunction:: int PyFile_Check(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyFileObject` or a subtype of
+   :ctype:`PyFileObject`.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyFile_CheckExact(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyFileObject`, but not a subtype of
+   :ctype:`PyFileObject`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyFile_FromString(char *filename, char *mode)
+
+   .. index:: single: fopen()
+
+   On success, return a new file object that is opened on the file given by
+   *filename*, with a file mode given by *mode*, where *mode* has the same
+   semantics as the standard C routine :cfunc:`fopen`.  On failure, return *NULL*.
+
+
+.. cfunction:: PyObject* PyFile_FromFile(FILE *fp, char *name, char *mode, int (*close)(FILE*))
+
+   Create a new :ctype:`PyFileObject` from the already-open standard C file
+   pointer, *fp*.  The function *close* will be called when the file should be
+   closed.  Return *NULL* on failure.
+
+
+.. cfunction:: FILE* PyFile_AsFile(PyObject *p)
+
+   Return the file object associated with *p* as a :ctype:`FILE\*`.
+
+
+.. cfunction:: PyObject* PyFile_GetLine(PyObject *p, int n)
+
+   .. index:: single: EOFError (built-in exception)
+
+   Equivalent to ``p.readline([n])``, this function reads one line from the
+   object *p*.  *p* may be a file object or any object with a :meth:`readline`
+   method.  If *n* is ``0``, exactly one line is read, regardless of the length of
+   the line.  If *n* is greater than ``0``, no more than *n* bytes will be read
+   from the file; a partial line can be returned.  In both cases, an empty string
+   is returned if the end of the file is reached immediately.  If *n* is less than
+   ``0``, however, one line is read regardless of length, but :exc:`EOFError` is
+   raised if the end of the file is reached immediately.
+
+
+.. cfunction:: PyObject* PyFile_Name(PyObject *p)
+
+   Return the name of the file specified by *p* as a string object.
+
+
+.. cfunction:: void PyFile_SetBufSize(PyFileObject *p, int n)
+
+   .. index:: single: setvbuf()
+
+   Available on systems with :cfunc:`setvbuf` only.  This should only be called
+   immediately after file object creation.
+
+
+.. cfunction:: int PyFile_Encoding(PyFileObject *p, char *enc)
+
+   Set the file's encoding for Unicode output to *enc*. Return 1 on success and 0
+   on failure.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: int PyFile_SoftSpace(PyObject *p, int newflag)
+
+   .. index:: single: softspace (file attribute)
+
+   This function exists for internal use by the interpreter.  Set the
+   :attr:`softspace` attribute of *p* to *newflag* and return the previous value.
+   *p* does not have to be a file object for this function to work properly; any
+   object is supported (thought its only interesting if the :attr:`softspace`
+   attribute can be set).  This function clears any errors, and will return ``0``
+   as the previous value if the attribute either does not exist or if there were
+   errors in retrieving it.  There is no way to detect errors from this function,
+   but doing so should not be needed.
+
+
+.. cfunction:: int PyFile_WriteObject(PyObject *obj, PyObject *p, int flags)
+
+   .. index:: single: Py_PRINT_RAW
+
+   Write object *obj* to file object *p*.  The only supported flag for *flags* is
+   :const:`Py_PRINT_RAW`; if given, the :func:`str` of the object is written
+   instead of the :func:`repr`.  Return ``0`` on success or ``-1`` on failure; the
+   appropriate exception will be set.
+
+
+.. cfunction:: int PyFile_WriteString(const char *s, PyObject *p)
+
+   Write string *s* to file object *p*.  Return ``0`` on success or ``-1`` on
+   failure; the appropriate exception will be set.
+
+
+.. _instanceobjects:
+
+Instance Objects
+----------------
+
+.. index:: object: instance
+
+There are very few functions specific to instance objects.
+
+
+.. cvar:: PyTypeObject PyInstance_Type
+
+   Type object for class instances.
+
+
+.. cfunction:: int PyInstance_Check(PyObject *obj)
+
+   Return true if *obj* is an instance.
+
+
+.. cfunction:: PyObject* PyInstance_New(PyObject *class, PyObject *arg, PyObject *kw)
+
+   Create a new instance of a specific class.  The parameters *arg* and *kw* are
+   used as the positional and keyword parameters to the object's constructor.
+
+
+.. cfunction:: PyObject* PyInstance_NewRaw(PyObject *class, PyObject *dict)
+
+   Create a new instance of a specific class without calling its constructor.
+   *class* is the class of new object.  The *dict* parameter will be used as the
+   object's :attr:`__dict__`; if *NULL*, a new dictionary will be created for the
+   instance.
+
+
+.. _function-objects:
+
+Function Objects
+----------------
+
+.. index:: object: function
+
+There are a few functions specific to Python functions.
+
+
+.. ctype:: PyFunctionObject
+
+   The C structure used for functions.
+
+
+.. cvar:: PyTypeObject PyFunction_Type
+
+   .. index:: single: MethodType (in module types)
+
+   This is an instance of :ctype:`PyTypeObject` and represents the Python function
+   type.  It is exposed to Python programmers as ``types.FunctionType``.
+
+
+.. cfunction:: int PyFunction_Check(PyObject *o)
+
+   Return true if *o* is a function object (has type :cdata:`PyFunction_Type`).
+   The parameter must not be *NULL*.
+
+
+.. cfunction:: PyObject* PyFunction_New(PyObject *code, PyObject *globals)
+
+   Return a new function object associated with the code object *code*. *globals*
+   must be a dictionary with the global variables accessible to the function.
+
+   The function's docstring, name and *__module__* are retrieved from the code
+   object, the argument defaults and closure are set to *NULL*.
+
+
+.. cfunction:: PyObject* PyFunction_GetCode(PyObject *op)
+
+   Return the code object associated with the function object *op*.
+
+
+.. cfunction:: PyObject* PyFunction_GetGlobals(PyObject *op)
+
+   Return the globals dictionary associated with the function object *op*.
+
+
+.. cfunction:: PyObject* PyFunction_GetModule(PyObject *op)
+
+   Return the *__module__* attribute of the function object *op*. This is normally
+   a string containing the module name, but can be set to any other object by
+   Python code.
+
+
+.. cfunction:: PyObject* PyFunction_GetDefaults(PyObject *op)
+
+   Return the argument default values of the function object *op*. This can be a
+   tuple of arguments or *NULL*.
+
+
+.. cfunction:: int PyFunction_SetDefaults(PyObject *op, PyObject *defaults)
+
+   Set the argument default values for the function object *op*. *defaults* must be
+   *Py_None* or a tuple.
+
+   Raises :exc:`SystemError` and returns ``-1`` on failure.
+
+
+.. cfunction:: PyObject* PyFunction_GetClosure(PyObject *op)
+
+   Return the closure associated with the function object *op*. This can be *NULL*
+   or a tuple of cell objects.
+
+
+.. cfunction:: int PyFunction_SetClosure(PyObject *op, PyObject *closure)
+
+   Set the closure associated with the function object *op*. *closure* must be
+   *Py_None* or a tuple of cell objects.
+
+   Raises :exc:`SystemError` and returns ``-1`` on failure.
+
+
+.. _method-objects:
+
+Method Objects
+--------------
+
+.. index:: object: method
+
+There are some useful functions that are useful for working with method objects.
+
+
+.. cvar:: PyTypeObject PyMethod_Type
+
+   .. index:: single: MethodType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python method type.  This
+   is exposed to Python programs as ``types.MethodType``.
+
+
+.. cfunction:: int PyMethod_Check(PyObject *o)
+
+   Return true if *o* is a method object (has type :cdata:`PyMethod_Type`).  The
+   parameter must not be *NULL*.
+
+
+.. cfunction:: PyObject* PyMethod_New(PyObject *func, PyObject *self, PyObject *class)
+
+   Return a new method object, with *func* being any callable object; this is the
+   function that will be called when the method is called.  If this method should
+   be bound to an instance, *self* should be the instance and *class* should be the
+   class of *self*, otherwise *self* should be *NULL* and *class* should be the
+   class which provides the unbound method..
+
+
+.. cfunction:: PyObject* PyMethod_Class(PyObject *meth)
+
+   Return the class object from which the method *meth* was created; if this was
+   created from an instance, it will be the class of the instance.
+
+
+.. cfunction:: PyObject* PyMethod_GET_CLASS(PyObject *meth)
+
+   Macro version of :cfunc:`PyMethod_Class` which avoids error checking.
+
+
+.. cfunction:: PyObject* PyMethod_Function(PyObject *meth)
+
+   Return the function object associated with the method *meth*.
+
+
+.. cfunction:: PyObject* PyMethod_GET_FUNCTION(PyObject *meth)
+
+   Macro version of :cfunc:`PyMethod_Function` which avoids error checking.
+
+
+.. cfunction:: PyObject* PyMethod_Self(PyObject *meth)
+
+   Return the instance associated with the method *meth* if it is bound, otherwise
+   return *NULL*.
+
+
+.. cfunction:: PyObject* PyMethod_GET_SELF(PyObject *meth)
+
+   Macro version of :cfunc:`PyMethod_Self` which avoids error checking.
+
+
+.. _moduleobjects:
+
+Module Objects
+--------------
+
+.. index:: object: module
+
+There are only a few functions special to module objects.
+
+
+.. cvar:: PyTypeObject PyModule_Type
+
+   .. index:: single: ModuleType (in module types)
+
+   This instance of :ctype:`PyTypeObject` represents the Python module type.  This
+   is exposed to Python programs as ``types.ModuleType``.
+
+
+.. cfunction:: int PyModule_Check(PyObject *p)
+
+   Return true if *p* is a module object, or a subtype of a module object.
+
+   .. versionchanged:: 2.2
+      Allowed subtypes to be accepted.
+
+
+.. cfunction:: int PyModule_CheckExact(PyObject *p)
+
+   Return true if *p* is a module object, but not a subtype of
+   :cdata:`PyModule_Type`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyModule_New(const char *name)
+
+   .. index::
+      single: __name__ (module attribute)
+      single: __doc__ (module attribute)
+      single: __file__ (module attribute)
+
+   Return a new module object with the :attr:`__name__` attribute set to *name*.
+   Only the module's :attr:`__doc__` and :attr:`__name__` attributes are filled in;
+   the caller is responsible for providing a :attr:`__file__` attribute.
+
+
+.. cfunction:: PyObject* PyModule_GetDict(PyObject *module)
+
+   .. index:: single: __dict__ (module attribute)
+
+   Return the dictionary object that implements *module*'s namespace; this object
+   is the same as the :attr:`__dict__` attribute of the module object.  This
+   function never fails.  It is recommended extensions use other
+   :cfunc:`PyModule_\*` and :cfunc:`PyObject_\*` functions rather than directly
+   manipulate a module's :attr:`__dict__`.
+
+
+.. cfunction:: char* PyModule_GetName(PyObject *module)
+
+   .. index::
+      single: __name__ (module attribute)
+      single: SystemError (built-in exception)
+
+   Return *module*'s :attr:`__name__` value.  If the module does not provide one,
+   or if it is not a string, :exc:`SystemError` is raised and *NULL* is returned.
+
+
+.. cfunction:: char* PyModule_GetFilename(PyObject *module)
+
+   .. index::
+      single: __file__ (module attribute)
+      single: SystemError (built-in exception)
+
+   Return the name of the file from which *module* was loaded using *module*'s
+   :attr:`__file__` attribute.  If this is not defined, or if it is not a string,
+   raise :exc:`SystemError` and return *NULL*.
+
+
+.. cfunction:: int PyModule_AddObject(PyObject *module, const char *name, PyObject *value)
+
+   Add an object to *module* as *name*.  This is a convenience function which can
+   be used from the module's initialization function.  This steals a reference to
+   *value*.  Return ``-1`` on error, ``0`` on success.
+
+   .. versionadded:: 2.0
+
+
+.. cfunction:: int PyModule_AddIntConstant(PyObject *module, const char *name, long value)
+
+   Add an integer constant to *module* as *name*.  This convenience function can be
+   used from the module's initialization function. Return ``-1`` on error, ``0`` on
+   success.
+
+   .. versionadded:: 2.0
+
+
+.. cfunction:: int PyModule_AddStringConstant(PyObject *module, const char *name, const char *value)
+
+   Add a string constant to *module* as *name*.  This convenience function can be
+   used from the module's initialization function.  The string *value* must be
+   null-terminated.  Return ``-1`` on error, ``0`` on success.
+
+   .. versionadded:: 2.0
+
+
+.. _iterator-objects:
+
+Iterator Objects
+----------------
+
+Python provides two general-purpose iterator objects.  The first, a sequence
+iterator, works with an arbitrary sequence supporting the :meth:`__getitem__`
+method.  The second works with a callable object and a sentinel value, calling
+the callable for each item in the sequence, and ending the iteration when the
+sentinel value is returned.
+
+
+.. cvar:: PyTypeObject PySeqIter_Type
+
+   Type object for iterator objects returned by :cfunc:`PySeqIter_New` and the
+   one-argument form of the :func:`iter` built-in function for built-in sequence
+   types.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PySeqIter_Check(op)
+
+   Return true if the type of *op* is :cdata:`PySeqIter_Type`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PySeqIter_New(PyObject *seq)
+
+   Return an iterator that works with a general sequence object, *seq*.  The
+   iteration ends when the sequence raises :exc:`IndexError` for the subscripting
+   operation.
+
+   .. versionadded:: 2.2
+
+
+.. cvar:: PyTypeObject PyCallIter_Type
+
+   Type object for iterator objects returned by :cfunc:`PyCallIter_New` and the
+   two-argument form of the :func:`iter` built-in function.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyCallIter_Check(op)
+
+   Return true if the type of *op* is :cdata:`PyCallIter_Type`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyCallIter_New(PyObject *callable, PyObject *sentinel)
+
+   Return a new iterator.  The first parameter, *callable*, can be any Python
+   callable object that can be called with no parameters; each call to it should
+   return the next item in the iteration.  When *callable* returns a value equal to
+   *sentinel*, the iteration will be terminated.
+
+   .. versionadded:: 2.2
+
+
+.. _descriptor-objects:
+
+Descriptor Objects
+------------------
+
+"Descriptors" are objects that describe some attribute of an object. They are
+found in the dictionary of type objects.
+
+
+.. cvar:: PyTypeObject PyProperty_Type
+
+   The type object for the built-in descriptor types.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyDescr_NewGetSet(PyTypeObject *type, struct PyGetSetDef *getset)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyDescr_NewMember(PyTypeObject *type, struct PyMemberDef *meth)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyDescr_NewMethod(PyTypeObject *type, struct PyMethodDef *meth)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyDescr_NewWrapper(PyTypeObject *type, struct wrapperbase *wrapper, void *wrapped)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyDescr_NewClassMethod(PyTypeObject *type, PyMethodDef *method)
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: int PyDescr_IsData(PyObject *descr)
+
+   Return true if the descriptor objects *descr* describes a data attribute, or
+   false if it describes a method.  *descr* must be a descriptor object; there is
+   no error checking.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyWrapper_New(PyObject *, PyObject *)
+
+   .. versionadded:: 2.2
+
+
+.. _slice-objects:
+
+Slice Objects
+-------------
+
+
+.. cvar:: PyTypeObject PySlice_Type
+
+   .. index:: single: SliceType (in module types)
+
+   The type object for slice objects.  This is the same as ``slice`` and
+   ``types.SliceType``.
+
+
+.. cfunction:: int PySlice_Check(PyObject *ob)
+
+   Return true if *ob* is a slice object; *ob* must not be *NULL*.
+
+
+.. cfunction:: PyObject* PySlice_New(PyObject *start, PyObject *stop, PyObject *step)
+
+   Return a new slice object with the given values.  The *start*, *stop*, and
+   *step* parameters are used as the values of the slice object attributes of the
+   same names.  Any of the values may be *NULL*, in which case the ``None`` will be
+   used for the corresponding attribute.  Return *NULL* if the new object could not
+   be allocated.
+
+
+.. cfunction:: int PySlice_GetIndices(PySliceObject *slice, Py_ssize_t length, Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step)
+
+   Retrieve the start, stop and step indices from the slice object *slice*,
+   assuming a sequence of length *length*. Treats indices greater than *length* as
+   errors.
+
+   Returns 0 on success and -1 on error with no exception set (unless one of the
+   indices was not :const:`None` and failed to be converted to an integer, in which
+   case -1 is returned with an exception set).
+
+   You probably do not want to use this function.  If you want to use slice objects
+   in versions of Python prior to 2.3, you would probably do well to incorporate
+   the source of :cfunc:`PySlice_GetIndicesEx`, suitably renamed, in the source of
+   your extension.
+
+
+.. cfunction:: int PySlice_GetIndicesEx(PySliceObject *slice, Py_ssize_t length, Py_ssize_t *start, Py_ssize_t *stop, Py_ssize_t *step, Py_ssize_t *slicelength)
+
+   Usable replacement for :cfunc:`PySlice_GetIndices`.  Retrieve the start, stop,
+   and step indices from the slice object *slice* assuming a sequence of length
+   *length*, and store the length of the slice in *slicelength*.  Out of bounds
+   indices are clipped in a manner consistent with the handling of normal slices.
+
+   Returns 0 on success and -1 on error with exception set.
+
+   .. versionadded:: 2.3
+
+
+.. _weakrefobjects:
+
+Weak Reference Objects
+----------------------
+
+Python supports *weak references* as first-class objects.  There are two
+specific object types which directly implement weak references.  The first is a
+simple reference object, and the second acts as a proxy for the original object
+as much as it can.
+
+
+.. cfunction:: int PyWeakref_Check(ob)
+
+   Return true if *ob* is either a reference or proxy object.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyWeakref_CheckRef(ob)
+
+   Return true if *ob* is a reference object.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: int PyWeakref_CheckProxy(ob)
+
+   Return true if *ob* is a proxy object.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyWeakref_NewRef(PyObject *ob, PyObject *callback)
+
+   Return a weak reference object for the object *ob*.  This will always return
+   a new reference, but is not guaranteed to create a new object; an existing
+   reference object may be returned.  The second parameter, *callback*, can be a
+   callable object that receives notification when *ob* is garbage collected; it
+   should accept a single parameter, which will be the weak reference object
+   itself. *callback* may also be ``None`` or *NULL*.  If *ob* is not a
+   weakly-referencable object, or if *callback* is not callable, ``None``, or
+   *NULL*, this will return *NULL* and raise :exc:`TypeError`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyWeakref_NewProxy(PyObject *ob, PyObject *callback)
+
+   Return a weak reference proxy object for the object *ob*.  This will always
+   return a new reference, but is not guaranteed to create a new object; an
+   existing proxy object may be returned.  The second parameter, *callback*, can
+   be a callable object that receives notification when *ob* is garbage
+   collected; it should accept a single parameter, which will be the weak
+   reference object itself. *callback* may also be ``None`` or *NULL*.  If *ob*
+   is not a weakly-referencable object, or if *callback* is not callable,
+   ``None``, or *NULL*, this will return *NULL* and raise :exc:`TypeError`.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyWeakref_GetObject(PyObject *ref)
+
+   Return the referenced object from a weak reference, *ref*.  If the referent is
+   no longer live, returns ``None``.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* PyWeakref_GET_OBJECT(PyObject *ref)
+
+   Similar to :cfunc:`PyWeakref_GetObject`, but implemented as a macro that does no
+   error checking.
+
+   .. versionadded:: 2.2
+
+
+.. _cobjects:
+
+CObjects
+--------
+
+.. index:: object: CObject
+
+Refer to *Extending and Embedding the Python Interpreter*, section 1.12,
+"Providing a C API for an Extension Module," for more information on using these
+objects.
+
+
+.. ctype:: PyCObject
+
+   This subtype of :ctype:`PyObject` represents an opaque value, useful for C
+   extension modules who need to pass an opaque value (as a :ctype:`void\*`
+   pointer) through Python code to other C code.  It is often used to make a C
+   function pointer defined in one module available to other modules, so the
+   regular import mechanism can be used to access C APIs defined in dynamically
+   loaded modules.
+
+
+.. cfunction:: int PyCObject_Check(PyObject *p)
+
+   Return true if its argument is a :ctype:`PyCObject`.
+
+
+.. cfunction:: PyObject* PyCObject_FromVoidPtr(void* cobj, void (*destr)(void *))
+
+   Create a :ctype:`PyCObject` from the ``void *`` *cobj*.  The *destr* function
+   will be called when the object is reclaimed, unless it is *NULL*.
+
+
+.. cfunction:: PyObject* PyCObject_FromVoidPtrAndDesc(void* cobj, void* desc, void (*destr)(void *, void *))
+
+   Create a :ctype:`PyCObject` from the :ctype:`void \*` *cobj*.  The *destr*
+   function will be called when the object is reclaimed. The *desc* argument can
+   be used to pass extra callback data for the destructor function.
+
+
+.. cfunction:: void* PyCObject_AsVoidPtr(PyObject* self)
+
+   Return the object :ctype:`void \*` that the :ctype:`PyCObject` *self* was
+   created with.
+
+
+.. cfunction:: void* PyCObject_GetDesc(PyObject* self)
+
+   Return the description :ctype:`void \*` that the :ctype:`PyCObject` *self* was
+   created with.
+
+
+.. cfunction:: int PyCObject_SetVoidPtr(PyObject* self, void* cobj)
+
+   Set the void pointer inside *self* to *cobj*. The :ctype:`PyCObject` must not
+   have an associated destructor. Return true on success, false on failure.
+
+
+.. _cell-objects:
+
+Cell Objects
+------------
+
+"Cell" objects are used to implement variables referenced by multiple scopes.
+For each such variable, a cell object is created to store the value; the local
+variables of each stack frame that references the value contains a reference to
+the cells from outer scopes which also use that variable.  When the value is
+accessed, the value contained in the cell is used instead of the cell object
+itself.  This de-referencing of the cell object requires support from the
+generated byte-code; these are not automatically de-referenced when accessed.
+Cell objects are not likely to be useful elsewhere.
+
+
+.. ctype:: PyCellObject
+
+   The C structure used for cell objects.
+
+
+.. cvar:: PyTypeObject PyCell_Type
+
+   The type object corresponding to cell objects.
+
+
+.. cfunction:: int PyCell_Check(ob)
+
+   Return true if *ob* is a cell object; *ob* must not be *NULL*.
+
+
+.. cfunction:: PyObject* PyCell_New(PyObject *ob)
+
+   Create and return a new cell object containing the value *ob*. The parameter may
+   be *NULL*.
+
+
+.. cfunction:: PyObject* PyCell_Get(PyObject *cell)
+
+   Return the contents of the cell *cell*.
+
+
+.. cfunction:: PyObject* PyCell_GET(PyObject *cell)
+
+   Return the contents of the cell *cell*, but without checking that *cell* is
+   non-*NULL* and a cell object.
+
+
+.. cfunction:: int PyCell_Set(PyObject *cell, PyObject *value)
+
+   Set the contents of the cell object *cell* to *value*.  This releases the
+   reference to any current content of the cell. *value* may be *NULL*.  *cell*
+   must be non-*NULL*; if it is not a cell object, ``-1`` will be returned.  On
+   success, ``0`` will be returned.
+
+
+.. cfunction:: void PyCell_SET(PyObject *cell, PyObject *value)
+
+   Sets the value of the cell object *cell* to *value*.  No reference counts are
+   adjusted, and no checks are made for safety; *cell* must be non-*NULL* and must
+   be a cell object.
+
+
+.. _gen-objects:
+
+Generator Objects
+-----------------
+
+Generator objects are what Python uses to implement generator iterators. They
+are normally created by iterating over a function that yields values, rather
+than explicitly calling :cfunc:`PyGen_New`.
+
+
+.. ctype:: PyGenObject
+
+   The C structure used for generator objects.
+
+
+.. cvar:: PyTypeObject PyGen_Type
+
+   The type object corresponding to generator objects
+
+
+.. cfunction:: int PyGen_Check(ob)
+
+   Return true if *ob* is a generator object; *ob* must not be *NULL*.
+
+
+.. cfunction:: int PyGen_CheckExact(ob)
+
+   Return true if *ob*'s type is *PyGen_Type* is a generator object; *ob* must not
+   be *NULL*.
+
+
+.. cfunction:: PyObject* PyGen_New(PyFrameObject *frame)
+
+   Create and return a new generator object based on the *frame* object. A
+   reference to *frame* is stolen by this function. The parameter must not be
+   *NULL*.
+
+
+.. _datetimeobjects:
+
+DateTime Objects
+----------------
+
+Various date and time objects are supplied by the :mod:`datetime` module.
+Before using any of these functions, the header file :file:`datetime.h` must be
+included in your source (note that this is not included by :file:`Python.h`),
+and the macro :cfunc:`PyDateTime_IMPORT` must be invoked.  The macro puts a
+pointer to a C structure into a static variable,  ``PyDateTimeAPI``, that is
+used by the following macros.
+
+Type-check macros:
+
+
+.. cfunction:: int PyDate_Check(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DateType` or a subtype of
+   :cdata:`PyDateTime_DateType`.  *ob* must not be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDate_CheckExact(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DateType`. *ob* must not be
+   *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_Check(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DateTimeType` or a subtype of
+   :cdata:`PyDateTime_DateTimeType`.  *ob* must not be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_CheckExact(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DateTimeType`. *ob* must not
+   be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyTime_Check(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_TimeType` or a subtype of
+   :cdata:`PyDateTime_TimeType`.  *ob* must not be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyTime_CheckExact(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_TimeType`. *ob* must not be
+   *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDelta_Check(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DeltaType` or a subtype of
+   :cdata:`PyDateTime_DeltaType`.  *ob* must not be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDelta_CheckExact(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_DeltaType`. *ob* must not be
+   *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyTZInfo_Check(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_TZInfoType` or a subtype of
+   :cdata:`PyDateTime_TZInfoType`.  *ob* must not be *NULL*.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyTZInfo_CheckExact(PyObject *ob)
+
+   Return true if *ob* is of type :cdata:`PyDateTime_TZInfoType`. *ob* must not be
+   *NULL*.
+
+   .. versionadded:: 2.4
+
+Macros to create objects:
+
+
+.. cfunction:: PyObject* PyDate_FromDate(int year, int month, int day)
+
+   Return a ``datetime.date`` object with the specified year, month and day.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyDateTime_FromDateAndTime(int year, int month, int day, int hour, int minute, int second, int usecond)
+
+   Return a ``datetime.datetime`` object with the specified year, month, day, hour,
+   minute, second and microsecond.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyTime_FromTime(int hour, int minute, int second, int usecond)
+
+   Return a ``datetime.time`` object with the specified hour, minute, second and
+   microsecond.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyDelta_FromDSU(int days, int seconds, int useconds)
+
+   Return a ``datetime.timedelta`` object representing the given number of days,
+   seconds and microseconds.  Normalization is performed so that the resulting
+   number of microseconds and seconds lie in the ranges documented for
+   ``datetime.timedelta`` objects.
+
+   .. versionadded:: 2.4
+
+Macros to extract fields from date objects.  The argument must be an instance of
+:cdata:`PyDateTime_Date`, including subclasses (such as
+:cdata:`PyDateTime_DateTime`).  The argument must not be *NULL*, and the type is
+not checked:
+
+
+.. cfunction:: int PyDateTime_GET_YEAR(PyDateTime_Date *o)
+
+   Return the year, as a positive int.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_GET_MONTH(PyDateTime_Date *o)
+
+   Return the month, as an int from 1 through 12.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_GET_DAY(PyDateTime_Date *o)
+
+   Return the day, as an int from 1 through 31.
+
+   .. versionadded:: 2.4
+
+Macros to extract fields from datetime objects.  The argument must be an
+instance of :cdata:`PyDateTime_DateTime`, including subclasses. The argument
+must not be *NULL*, and the type is not checked:
+
+
+.. cfunction:: int PyDateTime_DATE_GET_HOUR(PyDateTime_DateTime *o)
+
+   Return the hour, as an int from 0 through 23.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_DATE_GET_MINUTE(PyDateTime_DateTime *o)
+
+   Return the minute, as an int from 0 through 59.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_DATE_GET_SECOND(PyDateTime_DateTime *o)
+
+   Return the second, as an int from 0 through 59.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_DATE_GET_MICROSECOND(PyDateTime_DateTime *o)
+
+   Return the microsecond, as an int from 0 through 999999.
+
+   .. versionadded:: 2.4
+
+Macros to extract fields from time objects.  The argument must be an instance of
+:cdata:`PyDateTime_Time`, including subclasses. The argument must not be *NULL*,
+and the type is not checked:
+
+
+.. cfunction:: int PyDateTime_TIME_GET_HOUR(PyDateTime_Time *o)
+
+   Return the hour, as an int from 0 through 23.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_TIME_GET_MINUTE(PyDateTime_Time *o)
+
+   Return the minute, as an int from 0 through 59.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_TIME_GET_SECOND(PyDateTime_Time *o)
+
+   Return the second, as an int from 0 through 59.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int PyDateTime_TIME_GET_MICROSECOND(PyDateTime_Time *o)
+
+   Return the microsecond, as an int from 0 through 999999.
+
+   .. versionadded:: 2.4
+
+Macros for the convenience of modules implementing the DB API:
+
+
+.. cfunction:: PyObject* PyDateTime_FromTimestamp(PyObject *args)
+
+   Create and return a new ``datetime.datetime`` object given an argument tuple
+   suitable for passing to ``datetime.datetime.fromtimestamp()``.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* PyDate_FromTimestamp(PyObject *args)
+
+   Create and return a new ``datetime.date`` object given an argument tuple
+   suitable for passing to ``datetime.date.fromtimestamp()``.
+
+   .. versionadded:: 2.4
+
+
+.. _setobjects:
+
+Set Objects
+-----------
+
+.. sectionauthor:: Raymond D. Hettinger <python@rcn.com>
+
+
+.. index::
+   object: set
+   object: frozenset
+
+.. versionadded:: 2.5
+
+This section details the public API for :class:`set` and :class:`frozenset`
+objects.  Any functionality not listed below is best accessed using the either
+the abstract object protocol (including :cfunc:`PyObject_CallMethod`,
+:cfunc:`PyObject_RichCompareBool`, :cfunc:`PyObject_Hash`,
+:cfunc:`PyObject_Repr`, :cfunc:`PyObject_IsTrue`, :cfunc:`PyObject_Print`, and
+:cfunc:`PyObject_GetIter`) or the abstract number protocol (including
+:cfunc:`PyNumber_And`, :cfunc:`PyNumber_Subtract`, :cfunc:`PyNumber_Or`,
+:cfunc:`PyNumber_Xor`, :cfunc:`PyNumber_InPlaceAnd`,
+:cfunc:`PyNumber_InPlaceSubtract`, :cfunc:`PyNumber_InPlaceOr`, and
+:cfunc:`PyNumber_InPlaceXor`).
+
+
+.. ctype:: PySetObject
+
+   This subtype of :ctype:`PyObject` is used to hold the internal data for both
+   :class:`set` and :class:`frozenset` objects.  It is like a :ctype:`PyDictObject`
+   in that it is a fixed size for small sets (much like tuple storage) and will
+   point to a separate, variable sized block of memory for medium and large sized
+   sets (much like list storage). None of the fields of this structure should be
+   considered public and are subject to change.  All access should be done through
+   the documented API rather than by manipulating the values in the structure.
+
+
+.. cvar:: PyTypeObject PySet_Type
+
+   This is an instance of :ctype:`PyTypeObject` representing the Python
+   :class:`set` type.
+
+
+.. cvar:: PyTypeObject PyFrozenSet_Type
+
+   This is an instance of :ctype:`PyTypeObject` representing the Python
+   :class:`frozenset` type.
+
+The following type check macros work on pointers to any Python object. Likewise,
+the constructor functions work with any iterable Python object.
+
+
+.. cfunction:: int PyAnySet_Check(PyObject *p)
+
+   Return true if *p* is a :class:`set` object, a :class:`frozenset` object, or an
+   instance of a subtype.
+
+
+.. cfunction:: int PyAnySet_CheckExact(PyObject *p)
+
+   Return true if *p* is a :class:`set` object or a :class:`frozenset` object but
+   not an instance of a subtype.
+
+
+.. cfunction:: int PyFrozenSet_CheckExact(PyObject *p)
+
+   Return true if *p* is a :class:`frozenset` object but not an instance of a
+   subtype.
+
+
+.. cfunction:: PyObject* PySet_New(PyObject *iterable)
+
+   Return a new :class:`set` containing objects returned by the *iterable*.  The
+   *iterable* may be *NULL* to create a new empty set.  Return the new set on
+   success or *NULL* on failure.  Raise :exc:`TypeError` if *iterable* is not
+   actually iterable.  The constructor is also useful for copying a set
+   (``c=set(s)``).
+
+
+.. cfunction:: PyObject* PyFrozenSet_New(PyObject *iterable)
+
+   Return a new :class:`frozenset` containing objects returned by the *iterable*.
+   The *iterable* may be *NULL* to create a new empty frozenset.  Return the new
+   set on success or *NULL* on failure.  Raise :exc:`TypeError` if *iterable* is
+   not actually iterable.
+
+The following functions and macros are available for instances of :class:`set`
+or :class:`frozenset` or instances of their subtypes.
+
+
+.. cfunction:: int PySet_Size(PyObject *anyset)
+
+   .. index:: builtin: len
+
+   Return the length of a :class:`set` or :class:`frozenset` object. Equivalent to
+   ``len(anyset)``.  Raises a :exc:`PyExc_SystemError` if *anyset* is not a
+   :class:`set`, :class:`frozenset`, or an instance of a subtype.
+
+
+.. cfunction:: int PySet_GET_SIZE(PyObject *anyset)
+
+   Macro form of :cfunc:`PySet_Size` without error checking.
+
+
+.. cfunction:: int PySet_Contains(PyObject *anyset, PyObject *key)
+
+   Return 1 if found, 0 if not found, and -1 if an error is encountered.  Unlike
+   the Python :meth:`__contains__` method, this function does not automatically
+   convert unhashable sets into temporary frozensets.  Raise a :exc:`TypeError` if
+   the *key* is unhashable. Raise :exc:`PyExc_SystemError` if *anyset* is not a
+   :class:`set`, :class:`frozenset`, or an instance of a subtype.
+
+The following functions are available for instances of :class:`set` or its
+subtypes but not for instances of :class:`frozenset` or its subtypes.
+
+
+.. cfunction:: int PySet_Add(PyObject *set, PyObject *key)
+
+   Add *key* to a :class:`set` instance.  Does not apply to :class:`frozenset`
+   instances.  Return 0 on success or -1 on failure. Raise a :exc:`TypeError` if
+   the *key* is unhashable. Raise a :exc:`MemoryError` if there is no room to grow.
+   Raise a :exc:`SystemError` if *set* is an not an instance of :class:`set` or its
+   subtype.
+
+
+.. cfunction:: int PySet_Discard(PyObject *set, PyObject *key)
+
+   Return 1 if found and removed, 0 if not found (no action taken), and -1 if an
+   error is encountered.  Does not raise :exc:`KeyError` for missing keys.  Raise a
+   :exc:`TypeError` if the *key* is unhashable.  Unlike the Python :meth:`discard`
+   method, this function does not automatically convert unhashable sets into
+   temporary frozensets. Raise :exc:`PyExc_SystemError` if *set* is an not an
+   instance of :class:`set` or its subtype.
+
+
+.. cfunction:: PyObject* PySet_Pop(PyObject *set)
+
+   Return a new reference to an arbitrary object in the *set*, and removes the
+   object from the *set*.  Return *NULL* on failure.  Raise :exc:`KeyError` if the
+   set is empty. Raise a :exc:`SystemError` if *set* is an not an instance of
+   :class:`set` or its subtype.
+
+
+.. cfunction:: int PySet_Clear(PyObject *set)
+
+   Empty an existing set of all elements.
+
diff --git a/Doc/c-api/exceptions.rst b/Doc/c-api/exceptions.rst
new file mode 100644
index 0000000..68ac090
--- /dev/null
+++ b/Doc/c-api/exceptions.rst
@@ -0,0 +1,515 @@
+.. highlightlang:: c
+
+
+.. _exceptionhandling:
+
+******************
+Exception Handling
+******************
+
+The functions described in this chapter will let you handle and raise Python
+exceptions.  It is important to understand some of the basics of Python
+exception handling.  It works somewhat like the Unix :cdata:`errno` variable:
+there is a global indicator (per thread) of the last error that occurred.  Most
+functions don't clear this on success, but will set it to indicate the cause of
+the error on failure.  Most functions also return an error indicator, usually
+*NULL* if they are supposed to return a pointer, or ``-1`` if they return an
+integer (exception: the :cfunc:`PyArg_\*` functions return ``1`` for success and
+``0`` for failure).
+
+When a function must fail because some function it called failed, it generally
+doesn't set the error indicator; the function it called already set it.  It is
+responsible for either handling the error and clearing the exception or
+returning after cleaning up any resources it holds (such as object references or
+memory allocations); it should *not* continue normally if it is not prepared to
+handle the error.  If returning due to an error, it is important to indicate to
+the caller that an error has been set.  If the error is not handled or carefully
+propagated, additional calls into the Python/C API may not behave as intended
+and may fail in mysterious ways.
+
+The error indicator consists of three Python objects corresponding to the result
+of ``sys.exc_info()``.  API functions exist to interact with the error indicator
+in various ways.  There is a separate error indicator for each thread.
+
+.. % XXX Order of these should be more thoughtful.
+.. % Either alphabetical or some kind of structure.
+
+
+.. cfunction:: void PyErr_Print()
+
+   Print a standard traceback to ``sys.stderr`` and clear the error indicator.
+   Call this function only when the error indicator is set.  (Otherwise it will
+   cause a fatal error!)
+
+
+.. cfunction:: PyObject* PyErr_Occurred()
+
+   Test whether the error indicator is set.  If set, return the exception *type*
+   (the first argument to the last call to one of the :cfunc:`PyErr_Set\*`
+   functions or to :cfunc:`PyErr_Restore`).  If not set, return *NULL*.  You do not
+   own a reference to the return value, so you do not need to :cfunc:`Py_DECREF`
+   it.
+
+   .. note::
+
+      Do not compare the return value to a specific exception; use
+      :cfunc:`PyErr_ExceptionMatches` instead, shown below.  (The comparison could
+      easily fail since the exception may be an instance instead of a class, in the
+      case of a class exception, or it may the a subclass of the expected exception.)
+
+
+.. cfunction:: int PyErr_ExceptionMatches(PyObject *exc)
+
+   Equivalent to ``PyErr_GivenExceptionMatches(PyErr_Occurred(), exc)``.  This
+   should only be called when an exception is actually set; a memory access
+   violation will occur if no exception has been raised.
+
+
+.. cfunction:: int PyErr_GivenExceptionMatches(PyObject *given, PyObject *exc)
+
+   Return true if the *given* exception matches the exception in *exc*.  If *exc*
+   is a class object, this also returns true when *given* is an instance of a
+   subclass.  If *exc* is a tuple, all exceptions in the tuple (and recursively in
+   subtuples) are searched for a match.  If *given* is *NULL*, a memory access
+   violation will occur.
+
+
+.. cfunction:: void PyErr_NormalizeException(PyObject**exc, PyObject**val, PyObject**tb)
+
+   Under certain circumstances, the values returned by :cfunc:`PyErr_Fetch` below
+   can be "unnormalized", meaning that ``*exc`` is a class object but ``*val`` is
+   not an instance of the  same class.  This function can be used to instantiate
+   the class in that case.  If the values are already normalized, nothing happens.
+   The delayed normalization is implemented to improve performance.
+
+
+.. cfunction:: void PyErr_Clear()
+
+   Clear the error indicator.  If the error indicator is not set, there is no
+   effect.
+
+
+.. cfunction:: void PyErr_Fetch(PyObject **ptype, PyObject **pvalue, PyObject **ptraceback)
+
+   Retrieve the error indicator into three variables whose addresses are passed.
+   If the error indicator is not set, set all three variables to *NULL*.  If it is
+   set, it will be cleared and you own a reference to each object retrieved.  The
+   value and traceback object may be *NULL* even when the type object is not.
+
+   .. note::
+
+      This function is normally only used by code that needs to handle exceptions or
+      by code that needs to save and restore the error indicator temporarily.
+
+
+.. cfunction:: void PyErr_Restore(PyObject *type, PyObject *value, PyObject *traceback)
+
+   Set  the error indicator from the three objects.  If the error indicator is
+   already set, it is cleared first.  If the objects are *NULL*, the error
+   indicator is cleared.  Do not pass a *NULL* type and non-*NULL* value or
+   traceback.  The exception type should be a class.  Do not pass an invalid
+   exception type or value. (Violating these rules will cause subtle problems
+   later.)  This call takes away a reference to each object: you must own a
+   reference to each object before the call and after the call you no longer own
+   these references.  (If you don't understand this, don't use this function.  I
+   warned you.)
+
+   .. note::
+
+      This function is normally only used by code that needs to save and restore the
+      error indicator temporarily; use :cfunc:`PyErr_Fetch` to save the current
+      exception state.
+
+
+.. cfunction:: void PyErr_SetString(PyObject *type, const char *message)
+
+   This is the most common way to set the error indicator.  The first argument
+   specifies the exception type; it is normally one of the standard exceptions,
+   e.g. :cdata:`PyExc_RuntimeError`.  You need not increment its reference count.
+   The second argument is an error message; it is converted to a string object.
+
+
+.. cfunction:: void PyErr_SetObject(PyObject *type, PyObject *value)
+
+   This function is similar to :cfunc:`PyErr_SetString` but lets you specify an
+   arbitrary Python object for the "value" of the exception.
+
+
+.. cfunction:: PyObject* PyErr_Format(PyObject *exception, const char *format, ...)
+
+   This function sets the error indicator and returns *NULL*. *exception* should be
+   a Python exception (class, not an instance).  *format* should be a string,
+   containing format codes, similar to :cfunc:`printf`. The ``width.precision``
+   before a format code is parsed, but the width part is ignored.
+
+   .. % This should be exactly the same as the table in PyString_FromFormat.
+   .. % One should just refer to the other.
+   .. % The descriptions for %zd and %zu are wrong, but the truth is complicated
+   .. % because not all compilers support the %z width modifier -- we fake it
+   .. % when necessary via interpolating PY_FORMAT_SIZE_T.
+   .. % %u, %lu, %zu should have "new in Python 2.5" blurbs.
+
+   +-------------------+---------------+--------------------------------+
+   | Format Characters | Type          | Comment                        |
+   +===================+===============+================================+
+   | :attr:`%%`        | *n/a*         | The literal % character.       |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%c`        | int           | A single character,            |
+   |                   |               | represented as an C int.       |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%d`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%d")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%u`        | unsigned int  | Exactly equivalent to          |
+   |                   |               | ``printf("%u")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%ld`       | long          | Exactly equivalent to          |
+   |                   |               | ``printf("%ld")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%lu`       | unsigned long | Exactly equivalent to          |
+   |                   |               | ``printf("%lu")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%zd`       | Py_ssize_t    | Exactly equivalent to          |
+   |                   |               | ``printf("%zd")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%zu`       | size_t        | Exactly equivalent to          |
+   |                   |               | ``printf("%zu")``.             |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%i`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%i")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%x`        | int           | Exactly equivalent to          |
+   |                   |               | ``printf("%x")``.              |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%s`        | char\*        | A null-terminated C character  |
+   |                   |               | array.                         |
+   +-------------------+---------------+--------------------------------+
+   | :attr:`%p`        | void\*        | The hex representation of a C  |
+   |                   |               | pointer. Mostly equivalent to  |
+   |                   |               | ``printf("%p")`` except that   |
+   |                   |               | it is guaranteed to start with |
+   |                   |               | the literal ``0x`` regardless  |
+   |                   |               | of what the platform's         |
+   |                   |               | ``printf`` yields.             |
+   +-------------------+---------------+--------------------------------+
+
+   An unrecognized format character causes all the rest of the format string to be
+   copied as-is to the result string, and any extra arguments discarded.
+
+
+.. cfunction:: void PyErr_SetNone(PyObject *type)
+
+   This is a shorthand for ``PyErr_SetObject(type, Py_None)``.
+
+
+.. cfunction:: int PyErr_BadArgument()
+
+   This is a shorthand for ``PyErr_SetString(PyExc_TypeError, message)``, where
+   *message* indicates that a built-in operation was invoked with an illegal
+   argument.  It is mostly for internal use.
+
+
+.. cfunction:: PyObject* PyErr_NoMemory()
+
+   This is a shorthand for ``PyErr_SetNone(PyExc_MemoryError)``; it returns *NULL*
+   so an object allocation function can write ``return PyErr_NoMemory();`` when it
+   runs out of memory.
+
+
+.. cfunction:: PyObject* PyErr_SetFromErrno(PyObject *type)
+
+   .. index:: single: strerror()
+
+   This is a convenience function to raise an exception when a C library function
+   has returned an error and set the C variable :cdata:`errno`.  It constructs a
+   tuple object whose first item is the integer :cdata:`errno` value and whose
+   second item is the corresponding error message (gotten from :cfunc:`strerror`),
+   and then calls ``PyErr_SetObject(type, object)``.  On Unix, when the
+   :cdata:`errno` value is :const:`EINTR`, indicating an interrupted system call,
+   this calls :cfunc:`PyErr_CheckSignals`, and if that set the error indicator,
+   leaves it set to that.  The function always returns *NULL*, so a wrapper
+   function around a system call can write ``return PyErr_SetFromErrno(type);``
+   when the system call returns an error.
+
+
+.. cfunction:: PyObject* PyErr_SetFromErrnoWithFilename(PyObject *type, const char *filename)
+
+   Similar to :cfunc:`PyErr_SetFromErrno`, with the additional behavior that if
+   *filename* is not *NULL*, it is passed to the constructor of *type* as a third
+   parameter.  In the case of exceptions such as :exc:`IOError` and :exc:`OSError`,
+   this is used to define the :attr:`filename` attribute of the exception instance.
+
+
+.. cfunction:: PyObject* PyErr_SetFromWindowsErr(int ierr)
+
+   This is a convenience function to raise :exc:`WindowsError`. If called with
+   *ierr* of :cdata:`0`, the error code returned by a call to :cfunc:`GetLastError`
+   is used instead.  It calls the Win32 function :cfunc:`FormatMessage` to retrieve
+   the Windows description of error code given by *ierr* or :cfunc:`GetLastError`,
+   then it constructs a tuple object whose first item is the *ierr* value and whose
+   second item is the corresponding error message (gotten from
+   :cfunc:`FormatMessage`), and then calls ``PyErr_SetObject(PyExc_WindowsError,
+   object)``. This function always returns *NULL*. Availability: Windows.
+
+
+.. cfunction:: PyObject* PyErr_SetExcFromWindowsErr(PyObject *type, int ierr)
+
+   Similar to :cfunc:`PyErr_SetFromWindowsErr`, with an additional parameter
+   specifying the exception type to be raised. Availability: Windows.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: PyObject* PyErr_SetFromWindowsErrWithFilename(int ierr, const char *filename)
+
+   Similar to :cfunc:`PyErr_SetFromWindowsErr`, with the additional behavior that
+   if *filename* is not *NULL*, it is passed to the constructor of
+   :exc:`WindowsError` as a third parameter. Availability: Windows.
+
+
+.. cfunction:: PyObject* PyErr_SetExcFromWindowsErrWithFilename(PyObject *type, int ierr, char *filename)
+
+   Similar to :cfunc:`PyErr_SetFromWindowsErrWithFilename`, with an additional
+   parameter specifying the exception type to be raised. Availability: Windows.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: void PyErr_BadInternalCall()
+
+   This is a shorthand for ``PyErr_SetString(PyExc_TypeError, message)``, where
+   *message* indicates that an internal operation (e.g. a Python/C API function)
+   was invoked with an illegal argument.  It is mostly for internal use.
+
+
+.. cfunction:: int PyErr_WarnEx(PyObject *category, char *message, int stacklevel)
+
+   Issue a warning message.  The *category* argument is a warning category (see
+   below) or *NULL*; the *message* argument is a message string.  *stacklevel* is a
+   positive number giving a number of stack frames; the warning will be issued from
+   the  currently executing line of code in that stack frame.  A *stacklevel* of 1
+   is the function calling :cfunc:`PyErr_WarnEx`, 2 is  the function above that,
+   and so forth.
+
+   This function normally prints a warning message to *sys.stderr*; however, it is
+   also possible that the user has specified that warnings are to be turned into
+   errors, and in that case this will raise an exception.  It is also possible that
+   the function raises an exception because of a problem with the warning machinery
+   (the implementation imports the :mod:`warnings` module to do the heavy lifting).
+   The return value is ``0`` if no exception is raised, or ``-1`` if an exception
+   is raised.  (It is not possible to determine whether a warning message is
+   actually printed, nor what the reason is for the exception; this is
+   intentional.)  If an exception is raised, the caller should do its normal
+   exception handling (for example, :cfunc:`Py_DECREF` owned references and return
+   an error value).
+
+   Warning categories must be subclasses of :cdata:`Warning`; the default warning
+   category is :cdata:`RuntimeWarning`.  The standard Python warning categories are
+   available as global variables whose names are ``PyExc_`` followed by the Python
+   exception name. These have the type :ctype:`PyObject\*`; they are all class
+   objects. Their names are :cdata:`PyExc_Warning`, :cdata:`PyExc_UserWarning`,
+   :cdata:`PyExc_UnicodeWarning`, :cdata:`PyExc_DeprecationWarning`,
+   :cdata:`PyExc_SyntaxWarning`, :cdata:`PyExc_RuntimeWarning`, and
+   :cdata:`PyExc_FutureWarning`.  :cdata:`PyExc_Warning` is a subclass of
+   :cdata:`PyExc_Exception`; the other warning categories are subclasses of
+   :cdata:`PyExc_Warning`.
+
+   For information about warning control, see the documentation for the
+   :mod:`warnings` module and the :option:`-W` option in the command line
+   documentation.  There is no C API for warning control.
+
+
+.. cfunction:: int PyErr_WarnExplicit(PyObject *category, const char *message, const char *filename, int lineno, const char *module, PyObject *registry)
+
+   Issue a warning message with explicit control over all warning attributes.  This
+   is a straightforward wrapper around the Python function
+   :func:`warnings.warn_explicit`, see there for more information.  The *module*
+   and *registry* arguments may be set to *NULL* to get the default effect
+   described there.
+
+
+.. cfunction:: int PyErr_CheckSignals()
+
+   .. index::
+      module: signal
+      single: SIGINT
+      single: KeyboardInterrupt (built-in exception)
+
+   This function interacts with Python's signal handling.  It checks whether a
+   signal has been sent to the processes and if so, invokes the corresponding
+   signal handler.  If the :mod:`signal` module is supported, this can invoke a
+   signal handler written in Python.  In all cases, the default effect for
+   :const:`SIGINT` is to raise the  :exc:`KeyboardInterrupt` exception.  If an
+   exception is raised the error indicator is set and the function returns ``-1``;
+   otherwise the function returns ``0``.  The error indicator may or may not be
+   cleared if it was previously set.
+
+
+.. cfunction:: void PyErr_SetInterrupt()
+
+   .. index::
+      single: SIGINT
+      single: KeyboardInterrupt (built-in exception)
+
+   This function simulates the effect of a :const:`SIGINT` signal arriving --- the
+   next time :cfunc:`PyErr_CheckSignals` is called,  :exc:`KeyboardInterrupt` will
+   be raised.  It may be called without holding the interpreter lock.
+
+   .. % XXX This was described as obsolete, but is used in
+   .. % thread.interrupt_main() (used from IDLE), so it's still needed.
+
+
+.. cfunction:: PyObject* PyErr_NewException(char *name, PyObject *base, PyObject *dict)
+
+   This utility function creates and returns a new exception object. The *name*
+   argument must be the name of the new exception, a C string of the form
+   ``module.class``.  The *base* and *dict* arguments are normally *NULL*.  This
+   creates a class object derived from :exc:`Exception` (accessible in C as
+   :cdata:`PyExc_Exception`).
+
+   The :attr:`__module__` attribute of the new class is set to the first part (up
+   to the last dot) of the *name* argument, and the class name is set to the last
+   part (after the last dot).  The *base* argument can be used to specify alternate
+   base classes; it can either be only one class or a tuple of classes. The *dict*
+   argument can be used to specify a dictionary of class variables and methods.
+
+
+.. cfunction:: void PyErr_WriteUnraisable(PyObject *obj)
+
+   This utility function prints a warning message to ``sys.stderr`` when an
+   exception has been set but it is impossible for the interpreter to actually
+   raise the exception.  It is used, for example, when an exception occurs in an
+   :meth:`__del__` method.
+
+   The function is called with a single argument *obj* that identifies the context
+   in which the unraisable exception occurred. The repr of *obj* will be printed in
+   the warning message.
+
+
+.. _standardexceptions:
+
+Standard Exceptions
+===================
+
+All standard Python exceptions are available as global variables whose names are
+``PyExc_`` followed by the Python exception name.  These have the type
+:ctype:`PyObject\*`; they are all class objects.  For completeness, here are all
+the variables:
+
++------------------------------------+----------------------------+----------+
+| C Name                             | Python Name                | Notes    |
++====================================+============================+==========+
+| :cdata:`PyExc_BaseException`       | :exc:`BaseException`       | (1), (4) |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_Exception`           | :exc:`Exception`           | \(1)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_ArithmeticError`     | :exc:`ArithmeticError`     | \(1)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_LookupError`         | :exc:`LookupError`         | \(1)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_AssertionError`      | :exc:`AssertionError`      |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_AttributeError`      | :exc:`AttributeError`      |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_EOFError`            | :exc:`EOFError`            |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_EnvironmentError`    | :exc:`EnvironmentError`    | \(1)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_FloatingPointError`  | :exc:`FloatingPointError`  |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_IOError`             | :exc:`IOError`             |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_ImportError`         | :exc:`ImportError`         |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_IndexError`          | :exc:`IndexError`          |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_KeyError`            | :exc:`KeyError`            |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_KeyboardInterrupt`   | :exc:`KeyboardInterrupt`   |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_MemoryError`         | :exc:`MemoryError`         |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_NameError`           | :exc:`NameError`           |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_NotImplementedError` | :exc:`NotImplementedError` |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_OSError`             | :exc:`OSError`             |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_OverflowError`       | :exc:`OverflowError`       |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_ReferenceError`      | :exc:`ReferenceError`      | \(2)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_RuntimeError`        | :exc:`RuntimeError`        |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_SyntaxError`         | :exc:`SyntaxError`         |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_SystemError`         | :exc:`SystemError`         |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_SystemExit`          | :exc:`SystemExit`          |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_TypeError`           | :exc:`TypeError`           |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_ValueError`          | :exc:`ValueError`          |          |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_WindowsError`        | :exc:`WindowsError`        | \(3)     |
++------------------------------------+----------------------------+----------+
+| :cdata:`PyExc_ZeroDivisionError`   | :exc:`ZeroDivisionError`   |          |
++------------------------------------+----------------------------+----------+
+
+.. index::
+   single: PyExc_BaseException
+   single: PyExc_Exception
+   single: PyExc_ArithmeticError
+   single: PyExc_LookupError
+   single: PyExc_AssertionError
+   single: PyExc_AttributeError
+   single: PyExc_EOFError
+   single: PyExc_EnvironmentError
+   single: PyExc_FloatingPointError
+   single: PyExc_IOError
+   single: PyExc_ImportError
+   single: PyExc_IndexError
+   single: PyExc_KeyError
+   single: PyExc_KeyboardInterrupt
+   single: PyExc_MemoryError
+   single: PyExc_NameError
+   single: PyExc_NotImplementedError
+   single: PyExc_OSError
+   single: PyExc_OverflowError
+   single: PyExc_ReferenceError
+   single: PyExc_RuntimeError
+   single: PyExc_SyntaxError
+   single: PyExc_SystemError
+   single: PyExc_SystemExit
+   single: PyExc_TypeError
+   single: PyExc_ValueError
+   single: PyExc_WindowsError
+   single: PyExc_ZeroDivisionError
+
+Notes:
+
+(1)
+   This is a base class for other standard exceptions.
+
+(2)
+   This is the same as :exc:`weakref.ReferenceError`.
+
+(3)
+   Only defined on Windows; protect code that uses this by testing that the
+   preprocessor macro ``MS_WINDOWS`` is defined.
+
+(4)
+   .. versionadded:: 2.5
+
+
+Deprecation of String Exceptions
+================================
+
+.. index:: single: BaseException (built-in exception)
+
+All exceptions built into Python or provided in the standard library are derived
+from :exc:`BaseException`.
+
+String exceptions are still supported in the interpreter to allow existing code
+to run unmodified, but this will also change in a future release.
+
diff --git a/Doc/c-api/index.rst b/Doc/c-api/index.rst
new file mode 100644
index 0000000..c643312
--- /dev/null
+++ b/Doc/c-api/index.rst
@@ -0,0 +1,33 @@
+.. _c-api-index:
+
+##################################
+  Python/C API Reference Manual
+##################################
+
+:Release: |version|
+:Date: |today|
+
+This manual documents the API used by C and C++ programmers who want to write
+extension modules or embed Python.  It is a companion to :ref:`extending-index`,
+which describes the general principles of extension writing but does not
+document the API functions in detail.
+
+.. warning::
+
+   The current version of this document is somewhat incomplete. However, most of
+   the important functions, types and structures are described.
+
+
+.. toctree::
+   :maxdepth: 2
+
+   intro.rst
+   veryhigh.rst
+   refcounting.rst
+   exceptions.rst
+   utilities.rst
+   abstract.rst
+   concrete.rst
+   init.rst
+   memory.rst
+   newtypes.rst
diff --git a/Doc/c-api/init.rst b/Doc/c-api/init.rst
new file mode 100644
index 0000000..2509e0b
--- /dev/null
+++ b/Doc/c-api/init.rst
@@ -0,0 +1,936 @@
+.. highlightlang:: c
+
+
+.. _initialization:
+
+*****************************************
+Initialization, Finalization, and Threads
+*****************************************
+
+
+.. cfunction:: void Py_Initialize()
+
+   .. index::
+      single: Py_SetProgramName()
+      single: PyEval_InitThreads()
+      single: PyEval_ReleaseLock()
+      single: PyEval_AcquireLock()
+      single: modules (in module sys)
+      single: path (in module sys)
+      module: __builtin__
+      module: __main__
+      module: sys
+      triple: module; search; path
+      single: PySys_SetArgv()
+      single: Py_Finalize()
+
+   Initialize the Python interpreter.  In an application embedding  Python, this
+   should be called before using any other Python/C API functions; with the
+   exception of :cfunc:`Py_SetProgramName`, :cfunc:`PyEval_InitThreads`,
+   :cfunc:`PyEval_ReleaseLock`, and :cfunc:`PyEval_AcquireLock`. This initializes
+   the table of loaded modules (``sys.modules``), and creates the fundamental
+   modules :mod:`__builtin__`, :mod:`__main__` and :mod:`sys`.  It also initializes
+   the module search path (``sys.path``). It does not set ``sys.argv``; use
+   :cfunc:`PySys_SetArgv` for that.  This is a no-op when called for a second time
+   (without calling :cfunc:`Py_Finalize` first).  There is no return value; it is a
+   fatal error if the initialization fails.
+
+
+.. cfunction:: void Py_InitializeEx(int initsigs)
+
+   This function works like :cfunc:`Py_Initialize` if *initsigs* is 1. If
+   *initsigs* is 0, it skips initialization registration of signal handlers, which
+   might be useful when Python is embedded.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: int Py_IsInitialized()
+
+   Return true (nonzero) when the Python interpreter has been initialized, false
+   (zero) if not.  After :cfunc:`Py_Finalize` is called, this returns false until
+   :cfunc:`Py_Initialize` is called again.
+
+
+.. cfunction:: void Py_Finalize()
+
+   Undo all initializations made by :cfunc:`Py_Initialize` and subsequent use of
+   Python/C API functions, and destroy all sub-interpreters (see
+   :cfunc:`Py_NewInterpreter` below) that were created and not yet destroyed since
+   the last call to :cfunc:`Py_Initialize`.  Ideally, this frees all memory
+   allocated by the Python interpreter.  This is a no-op when called for a second
+   time (without calling :cfunc:`Py_Initialize` again first).  There is no return
+   value; errors during finalization are ignored.
+
+   This function is provided for a number of reasons.  An embedding application
+   might want to restart Python without having to restart the application itself.
+   An application that has loaded the Python interpreter from a dynamically
+   loadable library (or DLL) might want to free all memory allocated by Python
+   before unloading the DLL. During a hunt for memory leaks in an application a
+   developer might want to free all memory allocated by Python before exiting from
+   the application.
+
+   **Bugs and caveats:** The destruction of modules and objects in modules is done
+   in random order; this may cause destructors (:meth:`__del__` methods) to fail
+   when they depend on other objects (even functions) or modules.  Dynamically
+   loaded extension modules loaded by Python are not unloaded.  Small amounts of
+   memory allocated by the Python interpreter may not be freed (if you find a leak,
+   please report it).  Memory tied up in circular references between objects is not
+   freed.  Some memory allocated by extension modules may not be freed.  Some
+   extensions may not work properly if their initialization routine is called more
+   than once; this can happen if an application calls :cfunc:`Py_Initialize` and
+   :cfunc:`Py_Finalize` more than once.
+
+
+.. cfunction:: PyThreadState* Py_NewInterpreter()
+
+   .. index::
+      module: __builtin__
+      module: __main__
+      module: sys
+      single: stdout (in module sys)
+      single: stderr (in module sys)
+      single: stdin (in module sys)
+
+   Create a new sub-interpreter.  This is an (almost) totally separate environment
+   for the execution of Python code.  In particular, the new interpreter has
+   separate, independent versions of all imported modules, including the
+   fundamental modules :mod:`__builtin__`, :mod:`__main__` and :mod:`sys`.  The
+   table of loaded modules (``sys.modules``) and the module search path
+   (``sys.path``) are also separate.  The new environment has no ``sys.argv``
+   variable.  It has new standard I/O stream file objects ``sys.stdin``,
+   ``sys.stdout`` and ``sys.stderr`` (however these refer to the same underlying
+   :ctype:`FILE` structures in the C library).
+
+   The return value points to the first thread state created in the new
+   sub-interpreter.  This thread state is made in the current thread state.
+   Note that no actual thread is created; see the discussion of thread states
+   below.  If creation of the new interpreter is unsuccessful, *NULL* is
+   returned; no exception is set since the exception state is stored in the
+   current thread state and there may not be a current thread state.  (Like all
+   other Python/C API functions, the global interpreter lock must be held before
+   calling this function and is still held when it returns; however, unlike most
+   other Python/C API functions, there needn't be a current thread state on
+   entry.)
+
+   .. index::
+      single: Py_Finalize()
+      single: Py_Initialize()
+
+   Extension modules are shared between (sub-)interpreters as follows: the first
+   time a particular extension is imported, it is initialized normally, and a
+   (shallow) copy of its module's dictionary is squirreled away.  When the same
+   extension is imported by another (sub-)interpreter, a new module is initialized
+   and filled with the contents of this copy; the extension's ``init`` function is
+   not called.  Note that this is different from what happens when an extension is
+   imported after the interpreter has been completely re-initialized by calling
+   :cfunc:`Py_Finalize` and :cfunc:`Py_Initialize`; in that case, the extension's
+   ``initmodule`` function *is* called again.
+
+   .. index:: single: close() (in module os)
+
+   **Bugs and caveats:** Because sub-interpreters (and the main interpreter) are
+   part of the same process, the insulation between them isn't perfect --- for
+   example, using low-level file operations like  :func:`os.close` they can
+   (accidentally or maliciously) affect each other's open files.  Because of the
+   way extensions are shared between (sub-)interpreters, some extensions may not
+   work properly; this is especially likely when the extension makes use of
+   (static) global variables, or when the extension manipulates its module's
+   dictionary after its initialization.  It is possible to insert objects created
+   in one sub-interpreter into a namespace of another sub-interpreter; this should
+   be done with great care to avoid sharing user-defined functions, methods,
+   instances or classes between sub-interpreters, since import operations executed
+   by such objects may affect the wrong (sub-)interpreter's dictionary of loaded
+   modules.  (XXX This is a hard-to-fix bug that will be addressed in a future
+   release.)
+
+   Also note that the use of this functionality is incompatible with extension
+   modules such as PyObjC and ctypes that use the :cfunc:`PyGILState_\*` APIs (and
+   this is inherent in the way the :cfunc:`PyGILState_\*` functions work).  Simple
+   things may work, but confusing behavior will always be near.
+
+
+.. cfunction:: void Py_EndInterpreter(PyThreadState *tstate)
+
+   .. index:: single: Py_Finalize()
+
+   Destroy the (sub-)interpreter represented by the given thread state. The given
+   thread state must be the current thread state.  See the discussion of thread
+   states below.  When the call returns, the current thread state is *NULL*.  All
+   thread states associated with this interpreter are destroyed.  (The global
+   interpreter lock must be held before calling this function and is still held
+   when it returns.)  :cfunc:`Py_Finalize` will destroy all sub-interpreters that
+   haven't been explicitly destroyed at that point.
+
+
+.. cfunction:: void Py_SetProgramName(char *name)
+
+   .. index::
+      single: Py_Initialize()
+      single: main()
+      single: Py_GetPath()
+
+   This function should be called before :cfunc:`Py_Initialize` is called for
+   the first time, if it is called at all.  It tells the interpreter the value
+   of the ``argv[0]`` argument to the :cfunc:`main` function of the program.
+   This is used by :cfunc:`Py_GetPath` and some other functions below to find
+   the Python run-time libraries relative to the interpreter executable.  The
+   default value is ``'python'``.  The argument should point to a
+   zero-terminated character string in static storage whose contents will not
+   change for the duration of the program's execution.  No code in the Python
+   interpreter will change the contents of this storage.
+
+
+.. cfunction:: char* Py_GetProgramName()
+
+   .. index:: single: Py_SetProgramName()
+
+   Return the program name set with :cfunc:`Py_SetProgramName`, or the default.
+   The returned string points into static storage; the caller should not modify its
+   value.
+
+
+.. cfunction:: char* Py_GetPrefix()
+
+   Return the *prefix* for installed platform-independent files. This is derived
+   through a number of complicated rules from the program name set with
+   :cfunc:`Py_SetProgramName` and some environment variables; for example, if the
+   program name is ``'/usr/local/bin/python'``, the prefix is ``'/usr/local'``. The
+   returned string points into static storage; the caller should not modify its
+   value.  This corresponds to the :makevar:`prefix` variable in the top-level
+   :file:`Makefile` and the :option:`--prefix` argument to the :program:`configure`
+   script at build time.  The value is available to Python code as ``sys.prefix``.
+   It is only useful on Unix.  See also the next function.
+
+
+.. cfunction:: char* Py_GetExecPrefix()
+
+   Return the *exec-prefix* for installed platform-*dependent* files.  This is
+   derived through a number of complicated rules from the program name set with
+   :cfunc:`Py_SetProgramName` and some environment variables; for example, if the
+   program name is ``'/usr/local/bin/python'``, the exec-prefix is
+   ``'/usr/local'``.  The returned string points into static storage; the caller
+   should not modify its value.  This corresponds to the :makevar:`exec_prefix`
+   variable in the top-level :file:`Makefile` and the :option:`--exec-prefix`
+   argument to the :program:`configure` script at build  time.  The value is
+   available to Python code as ``sys.exec_prefix``.  It is only useful on Unix.
+
+   Background: The exec-prefix differs from the prefix when platform dependent
+   files (such as executables and shared libraries) are installed in a different
+   directory tree.  In a typical installation, platform dependent files may be
+   installed in the :file:`/usr/local/plat` subtree while platform independent may
+   be installed in :file:`/usr/local`.
+
+   Generally speaking, a platform is a combination of hardware and software
+   families, e.g.  Sparc machines running the Solaris 2.x operating system are
+   considered the same platform, but Intel machines running Solaris 2.x are another
+   platform, and Intel machines running Linux are yet another platform.  Different
+   major revisions of the same operating system generally also form different
+   platforms.  Non-Unix operating systems are a different story; the installation
+   strategies on those systems are so different that the prefix and exec-prefix are
+   meaningless, and set to the empty string. Note that compiled Python bytecode
+   files are platform independent (but not independent from the Python version by
+   which they were compiled!).
+
+   System administrators will know how to configure the :program:`mount` or
+   :program:`automount` programs to share :file:`/usr/local` between platforms
+   while having :file:`/usr/local/plat` be a different filesystem for each
+   platform.
+
+
+.. cfunction:: char* Py_GetProgramFullPath()
+
+   .. index::
+      single: Py_SetProgramName()
+      single: executable (in module sys)
+
+   Return the full program name of the Python executable; this is  computed as a
+   side-effect of deriving the default module search path  from the program name
+   (set by :cfunc:`Py_SetProgramName` above). The returned string points into
+   static storage; the caller should not modify its value.  The value is available
+   to Python code as ``sys.executable``.
+
+
+.. cfunction:: char* Py_GetPath()
+
+   .. index::
+      triple: module; search; path
+      single: path (in module sys)
+
+   Return the default module search path; this is computed from the  program name
+   (set by :cfunc:`Py_SetProgramName` above) and some environment variables.  The
+   returned string consists of a series of directory names separated by a platform
+   dependent delimiter character.  The delimiter character is ``':'`` on Unix and
+   Mac OS X, ``';'`` on Windows.  The returned string points into static storage;
+   the caller should not modify its value.  The value is available to Python code
+   as the list ``sys.path``, which may be modified to change the future search path
+   for loaded modules.
+
+   .. % XXX should give the exact rules
+
+
+.. cfunction:: const char* Py_GetVersion()
+
+   Return the version of this Python interpreter.  This is a string that looks
+   something like ::
+
+      "1.5 (#67, Dec 31 1997, 22:34:28) [GCC 2.7.2.2]"
+
+   .. index:: single: version (in module sys)
+
+   The first word (up to the first space character) is the current Python version;
+   the first three characters are the major and minor version separated by a
+   period.  The returned string points into static storage; the caller should not
+   modify its value.  The value is available to Python code as ``sys.version``.
+
+
+.. cfunction:: const char* Py_GetBuildNumber()
+
+   Return a string representing the Subversion revision that this Python executable
+   was built from.  This number is a string because it may contain a trailing 'M'
+   if Python was built from a mixed revision source tree.
+
+   .. versionadded:: 2.5
+
+
+.. cfunction:: const char* Py_GetPlatform()
+
+   .. index:: single: platform (in module sys)
+
+   Return the platform identifier for the current platform.  On Unix, this is
+   formed from the "official" name of the operating system, converted to lower
+   case, followed by the major revision number; e.g., for Solaris 2.x, which is
+   also known as SunOS 5.x, the value is ``'sunos5'``.  On Mac OS X, it is
+   ``'darwin'``.  On Windows, it is ``'win'``.  The returned string points into
+   static storage; the caller should not modify its value.  The value is available
+   to Python code as ``sys.platform``.
+
+
+.. cfunction:: const char* Py_GetCopyright()
+
+   Return the official copyright string for the current Python version, for example
+
+   ``'Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam'``
+
+   .. index:: single: copyright (in module sys)
+
+   The returned string points into static storage; the caller should not modify its
+   value.  The value is available to Python code as ``sys.copyright``.
+
+
+.. cfunction:: const char* Py_GetCompiler()
+
+   Return an indication of the compiler used to build the current Python version,
+   in square brackets, for example::
+
+      "[GCC 2.7.2.2]"
+
+   .. index:: single: version (in module sys)
+
+   The returned string points into static storage; the caller should not modify its
+   value.  The value is available to Python code as part of the variable
+   ``sys.version``.
+
+
+.. cfunction:: const char* Py_GetBuildInfo()
+
+   Return information about the sequence number and build date and time  of the
+   current Python interpreter instance, for example ::
+
+      "#67, Aug  1 1997, 22:34:28"
+
+   .. index:: single: version (in module sys)
+
+   The returned string points into static storage; the caller should not modify its
+   value.  The value is available to Python code as part of the variable
+   ``sys.version``.
+
+
+.. cfunction:: void PySys_SetArgv(int argc, char **argv)
+
+   .. index::
+      single: main()
+      single: Py_FatalError()
+      single: argv (in module sys)
+
+   Set ``sys.argv`` based on *argc* and *argv*.  These parameters are similar to
+   those passed to the program's :cfunc:`main` function with the difference that
+   the first entry should refer to the script file to be executed rather than the
+   executable hosting the Python interpreter.  If there isn't a script that will be
+   run, the first entry in *argv* can be an empty string.  If this function fails
+   to initialize ``sys.argv``, a fatal condition is signalled using
+   :cfunc:`Py_FatalError`.
+
+   .. % XXX impl. doesn't seem consistent in allowing 0/NULL for the params;
+   .. % check w/ Guido.
+
+.. % XXX Other PySys thingies (doesn't really belong in this chapter)
+
+
+.. _threads:
+
+Thread State and the Global Interpreter Lock
+============================================
+
+.. index::
+   single: global interpreter lock
+   single: interpreter lock
+   single: lock, interpreter
+
+The Python interpreter is not fully thread safe.  In order to support
+multi-threaded Python programs, there's a global lock that must be held by the
+current thread before it can safely access Python objects. Without the lock,
+even the simplest operations could cause problems in a multi-threaded program:
+for example, when two threads simultaneously increment the reference count of
+the same object, the reference count could end up being incremented only once
+instead of twice.
+
+.. index:: single: setcheckinterval() (in module sys)
+
+Therefore, the rule exists that only the thread that has acquired the global
+interpreter lock may operate on Python objects or call Python/C API functions.
+In order to support multi-threaded Python programs, the interpreter regularly
+releases and reacquires the lock --- by default, every 100 bytecode instructions
+(this can be changed with  :func:`sys.setcheckinterval`).  The lock is also
+released and reacquired around potentially blocking I/O operations like reading
+or writing a file, so that other threads can run while the thread that requests
+the I/O is waiting for the I/O operation to complete.
+
+.. index::
+   single: PyThreadState
+   single: PyThreadState
+
+The Python interpreter needs to keep some bookkeeping information separate per
+thread --- for this it uses a data structure called :ctype:`PyThreadState`.
+There's one global variable, however: the pointer to the current
+:ctype:`PyThreadState` structure.  While most thread packages have a way to
+store "per-thread global data," Python's internal platform independent thread
+abstraction doesn't support this yet.  Therefore, the current thread state must
+be manipulated explicitly.
+
+This is easy enough in most cases.  Most code manipulating the global
+interpreter lock has the following simple structure::
+
+   Save the thread state in a local variable.
+   Release the interpreter lock.
+   ...Do some blocking I/O operation...
+   Reacquire the interpreter lock.
+   Restore the thread state from the local variable.
+
+This is so common that a pair of macros exists to simplify it::
+
+   Py_BEGIN_ALLOW_THREADS
+   ...Do some blocking I/O operation...
+   Py_END_ALLOW_THREADS
+
+.. index::
+   single: Py_BEGIN_ALLOW_THREADS
+   single: Py_END_ALLOW_THREADS
+
+The :cmacro:`Py_BEGIN_ALLOW_THREADS` macro opens a new block and declares a
+hidden local variable; the :cmacro:`Py_END_ALLOW_THREADS` macro closes the
+block.  Another advantage of using these two macros is that when Python is
+compiled without thread support, they are defined empty, thus saving the thread
+state and lock manipulations.
+
+When thread support is enabled, the block above expands to the following code::
+
+   PyThreadState *_save;
+
+   _save = PyEval_SaveThread();
+   ...Do some blocking I/O operation...
+   PyEval_RestoreThread(_save);
+
+Using even lower level primitives, we can get roughly the same effect as
+follows::
+
+   PyThreadState *_save;
+
+   _save = PyThreadState_Swap(NULL);
+   PyEval_ReleaseLock();
+   ...Do some blocking I/O operation...
+   PyEval_AcquireLock();
+   PyThreadState_Swap(_save);
+
+.. index::
+   single: PyEval_RestoreThread()
+   single: errno
+   single: PyEval_SaveThread()
+   single: PyEval_ReleaseLock()
+   single: PyEval_AcquireLock()
+
+There are some subtle differences; in particular, :cfunc:`PyEval_RestoreThread`
+saves and restores the value of the  global variable :cdata:`errno`, since the
+lock manipulation does not guarantee that :cdata:`errno` is left alone.  Also,
+when thread support is disabled, :cfunc:`PyEval_SaveThread` and
+:cfunc:`PyEval_RestoreThread` don't manipulate the lock; in this case,
+:cfunc:`PyEval_ReleaseLock` and :cfunc:`PyEval_AcquireLock` are not available.
+This is done so that dynamically loaded extensions compiled with thread support
+enabled can be loaded by an interpreter that was compiled with disabled thread
+support.
+
+The global interpreter lock is used to protect the pointer to the current thread
+state.  When releasing the lock and saving the thread state, the current thread
+state pointer must be retrieved before the lock is released (since another
+thread could immediately acquire the lock and store its own thread state in the
+global variable). Conversely, when acquiring the lock and restoring the thread
+state, the lock must be acquired before storing the thread state pointer.
+
+Why am I going on with so much detail about this?  Because when threads are
+created from C, they don't have the global interpreter lock, nor is there a
+thread state data structure for them.  Such threads must bootstrap themselves
+into existence, by first creating a thread state data structure, then acquiring
+the lock, and finally storing their thread state pointer, before they can start
+using the Python/C API.  When they are done, they should reset the thread state
+pointer, release the lock, and finally free their thread state data structure.
+
+Beginning with version 2.3, threads can now take advantage of the
+:cfunc:`PyGILState_\*` functions to do all of the above automatically.  The
+typical idiom for calling into Python from a C thread is now::
+
+   PyGILState_STATE gstate;
+   gstate = PyGILState_Ensure();
+
+   /* Perform Python actions here.  */
+   result = CallSomeFunction();
+   /* evaluate result */
+
+   /* Release the thread. No Python API allowed beyond this point. */
+   PyGILState_Release(gstate);
+
+Note that the :cfunc:`PyGILState_\*` functions assume there is only one global
+interpreter (created automatically by :cfunc:`Py_Initialize`).  Python still
+supports the creation of additional interpreters (using
+:cfunc:`Py_NewInterpreter`), but mixing multiple interpreters and the
+:cfunc:`PyGILState_\*` API is unsupported.
+
+
+.. ctype:: PyInterpreterState
+
+   This data structure represents the state shared by a number of cooperating
+   threads.  Threads belonging to the same interpreter share their module
+   administration and a few other internal items. There are no public members in
+   this structure.
+
+   Threads belonging to different interpreters initially share nothing, except
+   process state like available memory, open file descriptors and such.  The global
+   interpreter lock is also shared by all threads, regardless of to which
+   interpreter they belong.
+
+
+.. ctype:: PyThreadState
+
+   This data structure represents the state of a single thread.  The only public
+   data member is :ctype:`PyInterpreterState \*`:attr:`interp`, which points to
+   this thread's interpreter state.
+
+
+.. cfunction:: void PyEval_InitThreads()
+
+   .. index::
+      single: PyEval_ReleaseLock()
+      single: PyEval_ReleaseThread()
+      single: PyEval_SaveThread()
+      single: PyEval_RestoreThread()
+
+   Initialize and acquire the global interpreter lock.  It should be called in the
+   main thread before creating a second thread or engaging in any other thread
+   operations such as :cfunc:`PyEval_ReleaseLock` or
+   ``PyEval_ReleaseThread(tstate)``. It is not needed before calling
+   :cfunc:`PyEval_SaveThread` or :cfunc:`PyEval_RestoreThread`.
+
+   .. index:: single: Py_Initialize()
+
+   This is a no-op when called for a second time.  It is safe to call this function
+   before calling :cfunc:`Py_Initialize`.
+
+   .. index:: module: thread
+
+   When only the main thread exists, no lock operations are needed. This is a
+   common situation (most Python programs do not use threads), and the lock
+   operations slow the interpreter down a bit. Therefore, the lock is not created
+   initially.  This situation is equivalent to having acquired the lock:  when
+   there is only a single thread, all object accesses are safe.  Therefore, when
+   this function initializes the lock, it also acquires it.  Before the Python
+   :mod:`thread` module creates a new thread, knowing that either it has the lock
+   or the lock hasn't been created yet, it calls :cfunc:`PyEval_InitThreads`.  When
+   this call returns, it is guaranteed that the lock has been created and that the
+   calling thread has acquired it.
+
+   It is **not** safe to call this function when it is unknown which thread (if
+   any) currently has the global interpreter lock.
+
+   This function is not available when thread support is disabled at compile time.
+
+
+.. cfunction:: int PyEval_ThreadsInitialized()
+
+   Returns a non-zero value if :cfunc:`PyEval_InitThreads` has been called.  This
+   function can be called without holding the lock, and therefore can be used to
+   avoid calls to the locking API when running single-threaded.  This function is
+   not available when thread support is disabled at compile time.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: void PyEval_AcquireLock()
+
+   Acquire the global interpreter lock.  The lock must have been created earlier.
+   If this thread already has the lock, a deadlock ensues.  This function is not
+   available when thread support is disabled at compile time.
+
+
+.. cfunction:: void PyEval_ReleaseLock()
+
+   Release the global interpreter lock.  The lock must have been created earlier.
+   This function is not available when thread support is disabled at compile time.
+
+
+.. cfunction:: void PyEval_AcquireThread(PyThreadState *tstate)
+
+   Acquire the global interpreter lock and set the current thread state to
+   *tstate*, which should not be *NULL*.  The lock must have been created earlier.
+   If this thread already has the lock, deadlock ensues.  This function is not
+   available when thread support is disabled at compile time.
+
+
+.. cfunction:: void PyEval_ReleaseThread(PyThreadState *tstate)
+
+   Reset the current thread state to *NULL* and release the global interpreter
+   lock.  The lock must have been created earlier and must be held by the current
+   thread.  The *tstate* argument, which must not be *NULL*, is only used to check
+   that it represents the current thread state --- if it isn't, a fatal error is
+   reported. This function is not available when thread support is disabled at
+   compile time.
+
+
+.. cfunction:: PyThreadState* PyEval_SaveThread()
+
+   Release the interpreter lock (if it has been created and thread support is
+   enabled) and reset the thread state to *NULL*, returning the previous thread
+   state (which is not *NULL*).  If the lock has been created, the current thread
+   must have acquired it.  (This function is available even when thread support is
+   disabled at compile time.)
+
+
+.. cfunction:: void PyEval_RestoreThread(PyThreadState *tstate)
+
+   Acquire the interpreter lock (if it has been created and thread support is
+   enabled) and set the thread state to *tstate*, which must not be *NULL*.  If the
+   lock has been created, the current thread must not have acquired it, otherwise
+   deadlock ensues.  (This function is available even when thread support is
+   disabled at compile time.)
+
+The following macros are normally used without a trailing semicolon; look for
+example usage in the Python source distribution.
+
+
+.. cmacro:: Py_BEGIN_ALLOW_THREADS
+
+   This macro expands to ``{ PyThreadState *_save; _save = PyEval_SaveThread();``.
+   Note that it contains an opening brace; it must be matched with a following
+   :cmacro:`Py_END_ALLOW_THREADS` macro.  See above for further discussion of this
+   macro.  It is a no-op when thread support is disabled at compile time.
+
+
+.. cmacro:: Py_END_ALLOW_THREADS
+
+   This macro expands to ``PyEval_RestoreThread(_save); }``. Note that it contains
+   a closing brace; it must be matched with an earlier
+   :cmacro:`Py_BEGIN_ALLOW_THREADS` macro.  See above for further discussion of
+   this macro.  It is a no-op when thread support is disabled at compile time.
+
+
+.. cmacro:: Py_BLOCK_THREADS
+
+   This macro expands to ``PyEval_RestoreThread(_save);``: it is equivalent to
+   :cmacro:`Py_END_ALLOW_THREADS` without the closing brace.  It is a no-op when
+   thread support is disabled at compile time.
+
+
+.. cmacro:: Py_UNBLOCK_THREADS
+
+   This macro expands to ``_save = PyEval_SaveThread();``: it is equivalent to
+   :cmacro:`Py_BEGIN_ALLOW_THREADS` without the opening brace and variable
+   declaration.  It is a no-op when thread support is disabled at compile time.
+
+All of the following functions are only available when thread support is enabled
+at compile time, and must be called only when the interpreter lock has been
+created.
+
+
+.. cfunction:: PyInterpreterState* PyInterpreterState_New()
+
+   Create a new interpreter state object.  The interpreter lock need not be held,
+   but may be held if it is necessary to serialize calls to this function.
+
+
+.. cfunction:: void PyInterpreterState_Clear(PyInterpreterState *interp)
+
+   Reset all information in an interpreter state object.  The interpreter lock must
+   be held.
+
+
+.. cfunction:: void PyInterpreterState_Delete(PyInterpreterState *interp)
+
+   Destroy an interpreter state object.  The interpreter lock need not be held.
+   The interpreter state must have been reset with a previous call to
+   :cfunc:`PyInterpreterState_Clear`.
+
+
+.. cfunction:: PyThreadState* PyThreadState_New(PyInterpreterState *interp)
+
+   Create a new thread state object belonging to the given interpreter object.  The
+   interpreter lock need not be held, but may be held if it is necessary to
+   serialize calls to this function.
+
+
+.. cfunction:: void PyThreadState_Clear(PyThreadState *tstate)
+
+   Reset all information in a thread state object.  The interpreter lock must be
+   held.
+
+
+.. cfunction:: void PyThreadState_Delete(PyThreadState *tstate)
+
+   Destroy a thread state object.  The interpreter lock need not be held.  The
+   thread state must have been reset with a previous call to
+   :cfunc:`PyThreadState_Clear`.
+
+
+.. cfunction:: PyThreadState* PyThreadState_Get()
+
+   Return the current thread state.  The interpreter lock must be held.  When the
+   current thread state is *NULL*, this issues a fatal error (so that the caller
+   needn't check for *NULL*).
+
+
+.. cfunction:: PyThreadState* PyThreadState_Swap(PyThreadState *tstate)
+
+   Swap the current thread state with the thread state given by the argument
+   *tstate*, which may be *NULL*.  The interpreter lock must be held.
+
+
+.. cfunction:: PyObject* PyThreadState_GetDict()
+
+   Return a dictionary in which extensions can store thread-specific state
+   information.  Each extension should use a unique key to use to store state in
+   the dictionary.  It is okay to call this function when no current thread state
+   is available. If this function returns *NULL*, no exception has been raised and
+   the caller should assume no current thread state is available.
+
+   .. versionchanged:: 2.3
+      Previously this could only be called when a current thread is active, and *NULL*
+      meant that an exception was raised.
+
+
+.. cfunction:: int PyThreadState_SetAsyncExc(long id, PyObject *exc)
+
+   Asynchronously raise an exception in a thread. The *id* argument is the thread
+   id of the target thread; *exc* is the exception object to be raised. This
+   function does not steal any references to *exc*. To prevent naive misuse, you
+   must write your own C extension to call this.  Must be called with the GIL held.
+   Returns the number of thread states modified; this is normally one, but will be
+   zero if the thread id isn't found.  If *exc* is :const:`NULL`, the pending
+   exception (if any) for the thread is cleared. This raises no exceptions.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: PyGILState_STATE PyGILState_Ensure()
+
+   Ensure that the current thread is ready to call the Python C API regardless of
+   the current state of Python, or of its thread lock. This may be called as many
+   times as desired by a thread as long as each call is matched with a call to
+   :cfunc:`PyGILState_Release`. In general, other thread-related APIs may be used
+   between :cfunc:`PyGILState_Ensure` and :cfunc:`PyGILState_Release` calls as long
+   as the thread state is restored to its previous state before the Release().  For
+   example, normal usage of the :cmacro:`Py_BEGIN_ALLOW_THREADS` and
+   :cmacro:`Py_END_ALLOW_THREADS` macros is acceptable.
+
+   The return value is an opaque "handle" to the thread state when
+   :cfunc:`PyGILState_Acquire` was called, and must be passed to
+   :cfunc:`PyGILState_Release` to ensure Python is left in the same state. Even
+   though recursive calls are allowed, these handles *cannot* be shared - each
+   unique call to :cfunc:`PyGILState_Ensure` must save the handle for its call to
+   :cfunc:`PyGILState_Release`.
+
+   When the function returns, the current thread will hold the GIL. Failure is a
+   fatal error.
+
+   .. versionadded:: 2.3
+
+
+.. cfunction:: void PyGILState_Release(PyGILState_STATE)
+
+   Release any resources previously acquired.  After this call, Python's state will
+   be the same as it was prior to the corresponding :cfunc:`PyGILState_Ensure` call
+   (but generally this state will be unknown to the caller, hence the use of the
+   GILState API.)
+
+   Every call to :cfunc:`PyGILState_Ensure` must be matched by a call to
+   :cfunc:`PyGILState_Release` on the same thread.
+
+   .. versionadded:: 2.3
+
+
+.. _profiling:
+
+Profiling and Tracing
+=====================
+
+.. sectionauthor:: Fred L. Drake, Jr. <fdrake@acm.org>
+
+
+The Python interpreter provides some low-level support for attaching profiling
+and execution tracing facilities.  These are used for profiling, debugging, and
+coverage analysis tools.
+
+Starting with Python 2.2, the implementation of this facility was substantially
+revised, and an interface from C was added.  This C interface allows the
+profiling or tracing code to avoid the overhead of calling through Python-level
+callable objects, making a direct C function call instead.  The essential
+attributes of the facility have not changed; the interface allows trace
+functions to be installed per-thread, and the basic events reported to the trace
+function are the same as had been reported to the Python-level trace functions
+in previous versions.
+
+
+.. ctype:: int (*Py_tracefunc)(PyObject *obj, PyFrameObject *frame, int what, PyObject *arg)
+
+   The type of the trace function registered using :cfunc:`PyEval_SetProfile` and
+   :cfunc:`PyEval_SetTrace`. The first parameter is the object passed to the
+   registration function as *obj*, *frame* is the frame object to which the event
+   pertains, *what* is one of the constants :const:`PyTrace_CALL`,
+   :const:`PyTrace_EXCEPTION`, :const:`PyTrace_LINE`, :const:`PyTrace_RETURN`,
+   :const:`PyTrace_C_CALL`, :const:`PyTrace_C_EXCEPTION`, or
+   :const:`PyTrace_C_RETURN`, and *arg* depends on the value of *what*:
+
+   +------------------------------+--------------------------------------+
+   | Value of *what*              | Meaning of *arg*                     |
+   +==============================+======================================+
+   | :const:`PyTrace_CALL`        | Always *NULL*.                       |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_EXCEPTION`   | Exception information as returned by |
+   |                              | :func:`sys.exc_info`.                |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_LINE`        | Always *NULL*.                       |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_RETURN`      | Value being returned to the caller.  |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_C_CALL`      | Name of function being called.       |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_C_EXCEPTION` | Always *NULL*.                       |
+   +------------------------------+--------------------------------------+
+   | :const:`PyTrace_C_RETURN`    | Always *NULL*.                       |
+   +------------------------------+--------------------------------------+
+
+
+.. cvar:: int PyTrace_CALL
+
+   The value of the *what* parameter to a :ctype:`Py_tracefunc` function when a new
+   call to a function or method is being reported, or a new entry into a generator.
+   Note that the creation of the iterator for a generator function is not reported
+   as there is no control transfer to the Python bytecode in the corresponding
+   frame.
+
+
+.. cvar:: int PyTrace_EXCEPTION
+
+   The value of the *what* parameter to a :ctype:`Py_tracefunc` function when an
+   exception has been raised.  The callback function is called with this value for
+   *what* when after any bytecode is processed after which the exception becomes
+   set within the frame being executed.  The effect of this is that as exception
+   propagation causes the Python stack to unwind, the callback is called upon
+   return to each frame as the exception propagates.  Only trace functions receives
+   these events; they are not needed by the profiler.
+
+
+.. cvar:: int PyTrace_LINE
+
+   The value passed as the *what* parameter to a trace function (but not a
+   profiling function) when a line-number event is being reported.
+
+
+.. cvar:: int PyTrace_RETURN
+
+   The value for the *what* parameter to :ctype:`Py_tracefunc` functions when a
+   call is returning without propagating an exception.
+
+
+.. cvar:: int PyTrace_C_CALL
+
+   The value for the *what* parameter to :ctype:`Py_tracefunc` functions when a C
+   function is about to be called.
+
+
+.. cvar:: int PyTrace_C_EXCEPTION
+
+   The value for the *what* parameter to :ctype:`Py_tracefunc` functions when a C
+   function has thrown an exception.
+
+
+.. cvar:: int PyTrace_C_RETURN
+
+   The value for the *what* parameter to :ctype:`Py_tracefunc` functions when a C
+   function has returned.
+
+
+.. cfunction:: void PyEval_SetProfile(Py_tracefunc func, PyObject *obj)
+
+   Set the profiler function to *func*.  The *obj* parameter is passed to the
+   function as its first parameter, and may be any Python object, or *NULL*.  If
+   the profile function needs to maintain state, using a different value for *obj*
+   for each thread provides a convenient and thread-safe place to store it.  The
+   profile function is called for all monitored events except the line-number
+   events.
+
+
+.. cfunction:: void PyEval_SetTrace(Py_tracefunc func, PyObject *obj)
+
+   Set the tracing function to *func*.  This is similar to
+   :cfunc:`PyEval_SetProfile`, except the tracing function does receive line-number
+   events.
+
+
+.. _advanced-debugging:
+
+Advanced Debugger Support
+=========================
+
+.. sectionauthor:: Fred L. Drake, Jr. <fdrake@acm.org>
+
+
+These functions are only intended to be used by advanced debugging tools.
+
+
+.. cfunction:: PyInterpreterState* PyInterpreterState_Head()
+
+   Return the interpreter state object at the head of the list of all such objects.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyInterpreterState* PyInterpreterState_Next(PyInterpreterState *interp)
+
+   Return the next interpreter state object after *interp* from the list of all
+   such objects.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyThreadState * PyInterpreterState_ThreadHead(PyInterpreterState *interp)
+
+   Return the a pointer to the first :ctype:`PyThreadState` object in the list of
+   threads associated with the interpreter *interp*.
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyThreadState* PyThreadState_Next(PyThreadState *tstate)
+
+   Return the next thread state object after *tstate* from the list of all such
+   objects belonging to the same :ctype:`PyInterpreterState` object.
+
+   .. versionadded:: 2.2
+
diff --git a/Doc/c-api/intro.rst b/Doc/c-api/intro.rst
new file mode 100644
index 0000000..60b0052
--- /dev/null
+++ b/Doc/c-api/intro.rst
@@ -0,0 +1,630 @@
+.. highlightlang:: c
+
+
+.. _api-intro:
+
+************
+Introduction
+************
+
+The Application Programmer's Interface to Python gives C and C++ programmers
+access to the Python interpreter at a variety of levels.  The API is equally
+usable from C++, but for brevity it is generally referred to as the Python/C
+API.  There are two fundamentally different reasons for using the Python/C API.
+The first reason is to write *extension modules* for specific purposes; these
+are C modules that extend the Python interpreter.  This is probably the most
+common use.  The second reason is to use Python as a component in a larger
+application; this technique is generally referred to as :dfn:`embedding` Python
+in an application.
+
+Writing an extension module is a relatively well-understood process,  where a
+"cookbook" approach works well.  There are several tools  that automate the
+process to some extent.  While people have embedded  Python in other
+applications since its early existence, the process of  embedding Python is less
+straightforward than writing an extension.
+
+Many API functions are useful independent of whether you're embedding  or
+extending Python; moreover, most applications that embed Python  will need to
+provide a custom extension as well, so it's probably a  good idea to become
+familiar with writing an extension before  attempting to embed Python in a real
+application.
+
+
+.. _api-includes:
+
+Include Files
+=============
+
+All function, type and macro definitions needed to use the Python/C API are
+included in your code by the following line::
+
+   #include "Python.h"
+
+This implies inclusion of the following standard headers: ``<stdio.h>``,
+``<string.h>``, ``<errno.h>``, ``<limits.h>``, and ``<stdlib.h>`` (if
+available).
+
+.. warning::
+
+   Since Python may define some pre-processor definitions which affect the standard
+   headers on some systems, you *must* include :file:`Python.h` before any standard
+   headers are included.
+
+All user visible names defined by Python.h (except those defined by the included
+standard headers) have one of the prefixes ``Py`` or ``_Py``.  Names beginning
+with ``_Py`` are for internal use by the Python implementation and should not be
+used by extension writers. Structure member names do not have a reserved prefix.
+
+**Important:** user code should never define names that begin with ``Py`` or
+``_Py``.  This confuses the reader, and jeopardizes the portability of the user
+code to future Python versions, which may define additional names beginning with
+one of these prefixes.
+
+The header files are typically installed with Python.  On Unix, these  are
+located in the directories :file:`{prefix}/include/pythonversion/` and
+:file:`{exec_prefix}/include/pythonversion/`, where :envvar:`prefix` and
+:envvar:`exec_prefix` are defined by the corresponding parameters to Python's
+:program:`configure` script and *version* is ``sys.version[:3]``.  On Windows,
+the headers are installed in :file:`{prefix}/include`, where :envvar:`prefix` is
+the installation directory specified to the installer.
+
+To include the headers, place both directories (if different) on your compiler's
+search path for includes.  Do *not* place the parent directories on the search
+path and then use ``#include <pythonX.Y/Python.h>``; this will break on
+multi-platform builds since the platform independent headers under
+:envvar:`prefix` include the platform specific headers from
+:envvar:`exec_prefix`.
+
+C++ users should note that though the API is defined entirely using C, the
+header files do properly declare the entry points to be ``extern "C"``, so there
+is no need to do anything special to use the API from C++.
+
+
+.. _api-objects:
+
+Objects, Types and Reference Counts
+===================================
+
+.. index:: object: type
+
+Most Python/C API functions have one or more arguments as well as a return value
+of type :ctype:`PyObject\*`.  This type is a pointer to an opaque data type
+representing an arbitrary Python object.  Since all Python object types are
+treated the same way by the Python language in most situations (e.g.,
+assignments, scope rules, and argument passing), it is only fitting that they
+should be represented by a single C type.  Almost all Python objects live on the
+heap: you never declare an automatic or static variable of type
+:ctype:`PyObject`, only pointer variables of type :ctype:`PyObject\*` can  be
+declared.  The sole exception are the type objects; since these must never be
+deallocated, they are typically static :ctype:`PyTypeObject` objects.
+
+All Python objects (even Python integers) have a :dfn:`type` and a
+:dfn:`reference count`.  An object's type determines what kind of object it is
+(e.g., an integer, a list, or a user-defined function; there are many more as
+explained in :ref:`types`).  For each of the well-known types there is a macro
+to check whether an object is of that type; for instance, ``PyList_Check(a)`` is
+true if (and only if) the object pointed to by *a* is a Python list.
+
+
+.. _api-refcounts:
+
+Reference Counts
+----------------
+
+The reference count is important because today's computers have a  finite (and
+often severely limited) memory size; it counts how many  different places there
+are that have a reference to an object.  Such a  place could be another object,
+or a global (or static) C variable, or  a local variable in some C function.
+When an object's reference count  becomes zero, the object is deallocated.  If
+it contains references to  other objects, their reference count is decremented.
+Those other  objects may be deallocated in turn, if this decrement makes their
+reference count become zero, and so on.  (There's an obvious problem  with
+objects that reference each other here; for now, the solution is  "don't do
+that.")
+
+.. index::
+   single: Py_INCREF()
+   single: Py_DECREF()
+
+Reference counts are always manipulated explicitly.  The normal way is  to use
+the macro :cfunc:`Py_INCREF` to increment an object's reference count by one,
+and :cfunc:`Py_DECREF` to decrement it by   one.  The :cfunc:`Py_DECREF` macro
+is considerably more complex than the incref one, since it must check whether
+the reference count becomes zero and then cause the object's deallocator to be
+called. The deallocator is a function pointer contained in the object's type
+structure.  The type-specific deallocator takes care of decrementing the
+reference counts for other objects contained in the object if this is a compound
+object type, such as a list, as well as performing any additional finalization
+that's needed.  There's no chance that the reference count can overflow; at
+least as many bits are used to hold the reference count as there are distinct
+memory locations in virtual memory (assuming ``sizeof(long) >= sizeof(char*)``).
+Thus, the reference count increment is a simple operation.
+
+It is not necessary to increment an object's reference count for every  local
+variable that contains a pointer to an object.  In theory, the  object's
+reference count goes up by one when the variable is made to  point to it and it
+goes down by one when the variable goes out of  scope.  However, these two
+cancel each other out, so at the end the  reference count hasn't changed.  The
+only real reason to use the  reference count is to prevent the object from being
+deallocated as  long as our variable is pointing to it.  If we know that there
+is at  least one other reference to the object that lives at least as long as
+our variable, there is no need to increment the reference count  temporarily.
+An important situation where this arises is in objects  that are passed as
+arguments to C functions in an extension module  that are called from Python;
+the call mechanism guarantees to hold a  reference to every argument for the
+duration of the call.
+
+However, a common pitfall is to extract an object from a list and hold on to it
+for a while without incrementing its reference count. Some other operation might
+conceivably remove the object from the list, decrementing its reference count
+and possible deallocating it. The real danger is that innocent-looking
+operations may invoke arbitrary Python code which could do this; there is a code
+path which allows control to flow back to the user from a :cfunc:`Py_DECREF`, so
+almost any operation is potentially dangerous.
+
+A safe approach is to always use the generic operations (functions  whose name
+begins with ``PyObject_``, ``PyNumber_``, ``PySequence_`` or ``PyMapping_``).
+These operations always increment the reference count of the object they return.
+This leaves the caller with the responsibility to call :cfunc:`Py_DECREF` when
+they are done with the result; this soon becomes second nature.
+
+
+.. _api-refcountdetails:
+
+Reference Count Details
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The reference count behavior of functions in the Python/C API is best  explained
+in terms of *ownership of references*.  Ownership pertains to references, never
+to objects (objects are not owned: they are always shared).  "Owning a
+reference" means being responsible for calling Py_DECREF on it when the
+reference is no longer needed.  Ownership can also be transferred, meaning that
+the code that receives ownership of the reference then becomes responsible for
+eventually decref'ing it by calling :cfunc:`Py_DECREF` or :cfunc:`Py_XDECREF`
+when it's no longer needed---or passing on this responsibility (usually to its
+caller). When a function passes ownership of a reference on to its caller, the
+caller is said to receive a *new* reference.  When no ownership is transferred,
+the caller is said to *borrow* the reference. Nothing needs to be done for a
+borrowed reference.
+
+Conversely, when a calling function passes it a reference to an  object, there
+are two possibilities: the function *steals* a  reference to the object, or it
+does not.  *Stealing a reference* means that when you pass a reference to a
+function, that function assumes that it now owns that reference, and you are not
+responsible for it any longer.
+
+.. index::
+   single: PyList_SetItem()
+   single: PyTuple_SetItem()
+
+Few functions steal references; the two notable exceptions are
+:cfunc:`PyList_SetItem` and :cfunc:`PyTuple_SetItem`, which  steal a reference
+to the item (but not to the tuple or list into which the item is put!).  These
+functions were designed to steal a reference because of a common idiom for
+populating a tuple or list with newly created objects; for example, the code to
+create the tuple ``(1, 2, "three")`` could look like this (forgetting about
+error handling for the moment; a better way to code this is shown below)::
+
+   PyObject *t;
+
+   t = PyTuple_New(3);
+   PyTuple_SetItem(t, 0, PyInt_FromLong(1L));
+   PyTuple_SetItem(t, 1, PyInt_FromLong(2L));
+   PyTuple_SetItem(t, 2, PyString_FromString("three"));
+
+Here, :cfunc:`PyInt_FromLong` returns a new reference which is immediately
+stolen by :cfunc:`PyTuple_SetItem`.  When you want to keep using an object
+although the reference to it will be stolen, use :cfunc:`Py_INCREF` to grab
+another reference before calling the reference-stealing function.
+
+Incidentally, :cfunc:`PyTuple_SetItem` is the *only* way to set tuple items;
+:cfunc:`PySequence_SetItem` and :cfunc:`PyObject_SetItem` refuse to do this
+since tuples are an immutable data type.  You should only use
+:cfunc:`PyTuple_SetItem` for tuples that you are creating yourself.
+
+Equivalent code for populating a list can be written using :cfunc:`PyList_New`
+and :cfunc:`PyList_SetItem`.
+
+However, in practice, you will rarely use these ways of creating and populating
+a tuple or list.  There's a generic function, :cfunc:`Py_BuildValue`, that can
+create most common objects from C values, directed by a :dfn:`format string`.
+For example, the above two blocks of code could be replaced by the following
+(which also takes care of the error checking)::
+
+   PyObject *tuple, *list;
+
+   tuple = Py_BuildValue("(iis)", 1, 2, "three");
+   list = Py_BuildValue("[iis]", 1, 2, "three");
+
+It is much more common to use :cfunc:`PyObject_SetItem` and friends with items
+whose references you are only borrowing, like arguments that were passed in to
+the function you are writing.  In that case, their behaviour regarding reference
+counts is much saner, since you don't have to increment a reference count so you
+can give a reference away ("have it be stolen").  For example, this function
+sets all items of a list (actually, any mutable sequence) to a given item::
+
+   int
+   set_all(PyObject *target, PyObject *item)
+   {
+       int i, n;
+
+       n = PyObject_Length(target);
+       if (n < 0)
+           return -1;
+       for (i = 0; i < n; i++) {
+           PyObject *index = PyInt_FromLong(i);
+           if (!index)
+               return -1;
+           if (PyObject_SetItem(target, index, item) < 0)
+               return -1;
+           Py_DECREF(index);
+       }
+       return 0;
+   }
+
+.. index:: single: set_all()
+
+The situation is slightly different for function return values.   While passing
+a reference to most functions does not change your  ownership responsibilities
+for that reference, many functions that  return a reference to an object give
+you ownership of the reference. The reason is simple: in many cases, the
+returned object is created  on the fly, and the reference you get is the only
+reference to the  object.  Therefore, the generic functions that return object
+references, like :cfunc:`PyObject_GetItem` and  :cfunc:`PySequence_GetItem`,
+always return a new reference (the caller becomes the owner of the reference).
+
+It is important to realize that whether you own a reference returned  by a
+function depends on which function you call only --- *the plumage* (the type of
+the object passed as an argument to the function) *doesn't enter into it!*
+Thus, if you  extract an item from a list using :cfunc:`PyList_GetItem`, you
+don't own the reference --- but if you obtain the same item from the same list
+using :cfunc:`PySequence_GetItem` (which happens to take exactly the same
+arguments), you do own a reference to the returned object.
+
+.. index::
+   single: PyList_GetItem()
+   single: PySequence_GetItem()
+
+Here is an example of how you could write a function that computes the sum of
+the items in a list of integers; once using  :cfunc:`PyList_GetItem`, and once
+using :cfunc:`PySequence_GetItem`. ::
+
+   long
+   sum_list(PyObject *list)
+   {
+       int i, n;
+       long total = 0;
+       PyObject *item;
+
+       n = PyList_Size(list);
+       if (n < 0)
+           return -1; /* Not a list */
+       for (i = 0; i < n; i++) {
+           item = PyList_GetItem(list, i); /* Can't fail */
+           if (!PyInt_Check(item)) continue; /* Skip non-integers */
+           total += PyInt_AsLong(item);
+       }
+       return total;
+   }
+
+.. index:: single: sum_list()
+
+::
+
+   long
+   sum_sequence(PyObject *sequence)
+   {
+       int i, n;
+       long total = 0;
+       PyObject *item;
+       n = PySequence_Length(sequence);
+       if (n < 0)
+           return -1; /* Has no length */
+       for (i = 0; i < n; i++) {
+           item = PySequence_GetItem(sequence, i);
+           if (item == NULL)
+               return -1; /* Not a sequence, or other failure */
+           if (PyInt_Check(item))
+               total += PyInt_AsLong(item);
+           Py_DECREF(item); /* Discard reference ownership */
+       }
+       return total;
+   }
+
+.. index:: single: sum_sequence()
+
+
+.. _api-types:
+
+Types
+-----
+
+There are few other data types that play a significant role in  the Python/C
+API; most are simple C types such as :ctype:`int`,  :ctype:`long`,
+:ctype:`double` and :ctype:`char\*`.  A few structure types  are used to
+describe static tables used to list the functions exported  by a module or the
+data attributes of a new object type, and another is used to describe the value
+of a complex number.  These will  be discussed together with the functions that
+use them.
+
+
+.. _api-exceptions:
+
+Exceptions
+==========
+
+The Python programmer only needs to deal with exceptions if specific  error
+handling is required; unhandled exceptions are automatically  propagated to the
+caller, then to the caller's caller, and so on, until they reach the top-level
+interpreter, where they are reported to the  user accompanied by a stack
+traceback.
+
+.. index:: single: PyErr_Occurred()
+
+For C programmers, however, error checking always has to be explicit.   All
+functions in the Python/C API can raise exceptions, unless an  explicit claim is
+made otherwise in a function's documentation.  In  general, when a function
+encounters an error, it sets an exception,  discards any object references that
+it owns, and returns an  error indicator --- usually *NULL* or ``-1``.  A few
+functions  return a Boolean true/false result, with false indicating an error.
+Very few functions return no explicit error indicator or have an  ambiguous
+return value, and require explicit testing for errors with
+:cfunc:`PyErr_Occurred`.
+
+.. index::
+   single: PyErr_SetString()
+   single: PyErr_Clear()
+
+Exception state is maintained in per-thread storage (this is  equivalent to
+using global storage in an unthreaded application).  A  thread can be in one of
+two states: an exception has occurred, or not. The function
+:cfunc:`PyErr_Occurred` can be used to check for this: it returns a borrowed
+reference to the exception type object when an exception has occurred, and
+*NULL* otherwise.  There are a number of functions to set the exception state:
+:cfunc:`PyErr_SetString` is the most common (though not the most general)
+function to set the exception state, and :cfunc:`PyErr_Clear` clears the
+exception state.
+
+The full exception state consists of three objects (all of which can  be
+*NULL*): the exception type, the corresponding exception  value, and the
+traceback.  These have the same meanings as the Python result of
+``sys.exc_info()``; however, they are not the same: the Python objects represent
+the last exception being handled by a Python  :keyword:`try` ...
+:keyword:`except` statement, while the C level exception state only exists while
+an exception is being passed on between C functions until it reaches the Python
+bytecode interpreter's  main loop, which takes care of transferring it to
+``sys.exc_info()`` and friends.
+
+.. index:: single: exc_info() (in module sys)
+
+Note that starting with Python 1.5, the preferred, thread-safe way to access the
+exception state from Python code is to call the function :func:`sys.exc_info`,
+which returns the per-thread exception state for Python code.  Also, the
+semantics of both ways to access the exception state have changed so that a
+function which catches an exception will save and restore its thread's exception
+state so as to preserve the exception state of its caller.  This prevents common
+bugs in exception handling code caused by an innocent-looking function
+overwriting the exception being handled; it also reduces the often unwanted
+lifetime extension for objects that are referenced by the stack frames in the
+traceback.
+
+As a general principle, a function that calls another function to  perform some
+task should check whether the called function raised an  exception, and if so,
+pass the exception state on to its caller.  It  should discard any object
+references that it owns, and return an  error indicator, but it should *not* set
+another exception --- that would overwrite the exception that was just raised,
+and lose important information about the exact cause of the error.
+
+.. index:: single: sum_sequence()
+
+A simple example of detecting exceptions and passing them on is shown in the
+:cfunc:`sum_sequence` example above.  It so happens that that example doesn't
+need to clean up any owned references when it detects an error.  The following
+example function shows some error cleanup.  First, to remind you why you like
+Python, we show the equivalent Python code::
+
+   def incr_item(dict, key):
+       try:
+           item = dict[key]
+       except KeyError:
+           item = 0
+       dict[key] = item + 1
+
+.. index:: single: incr_item()
+
+Here is the corresponding C code, in all its glory::
+
+   int
+   incr_item(PyObject *dict, PyObject *key)
+   {
+       /* Objects all initialized to NULL for Py_XDECREF */
+       PyObject *item = NULL, *const_one = NULL, *incremented_item = NULL;
+       int rv = -1; /* Return value initialized to -1 (failure) */
+
+       item = PyObject_GetItem(dict, key);
+       if (item == NULL) {
+           /* Handle KeyError only: */
+           if (!PyErr_ExceptionMatches(PyExc_KeyError))
+               goto error;
+
+           /* Clear the error and use zero: */
+           PyErr_Clear();
+           item = PyInt_FromLong(0L);
+           if (item == NULL)
+               goto error;
+       }
+       const_one = PyInt_FromLong(1L);
+       if (const_one == NULL)
+           goto error;
+
+       incremented_item = PyNumber_Add(item, const_one);
+       if (incremented_item == NULL)
+           goto error;
+
+       if (PyObject_SetItem(dict, key, incremented_item) < 0)
+           goto error;
+       rv = 0; /* Success */
+       /* Continue with cleanup code */
+
+    error:
+       /* Cleanup code, shared by success and failure path */
+
+       /* Use Py_XDECREF() to ignore NULL references */
+       Py_XDECREF(item);
+       Py_XDECREF(const_one);
+       Py_XDECREF(incremented_item);
+
+       return rv; /* -1 for error, 0 for success */
+   }
+
+.. index:: single: incr_item()
+
+.. index::
+   single: PyErr_ExceptionMatches()
+   single: PyErr_Clear()
+   single: Py_XDECREF()
+
+This example represents an endorsed use of the :keyword:`goto` statement  in C!
+It illustrates the use of :cfunc:`PyErr_ExceptionMatches` and
+:cfunc:`PyErr_Clear` to handle specific exceptions, and the use of
+:cfunc:`Py_XDECREF` to dispose of owned references that may be *NULL* (note the
+``'X'`` in the name; :cfunc:`Py_DECREF` would crash when confronted with a
+*NULL* reference).  It is important that the variables used to hold owned
+references are initialized to *NULL* for this to work; likewise, the proposed
+return value is initialized to ``-1`` (failure) and only set to success after
+the final call made is successful.
+
+
+.. _api-embedding:
+
+Embedding Python
+================
+
+The one important task that only embedders (as opposed to extension writers) of
+the Python interpreter have to worry about is the initialization, and possibly
+the finalization, of the Python interpreter.  Most functionality of the
+interpreter can only be used after the interpreter has been initialized.
+
+.. index::
+   single: Py_Initialize()
+   module: __builtin__
+   module: __main__
+   module: sys
+   module: exceptions
+   triple: module; search; path
+   single: path (in module sys)
+
+The basic initialization function is :cfunc:`Py_Initialize`. This initializes
+the table of loaded modules, and creates the fundamental modules
+:mod:`__builtin__`, :mod:`__main__`, :mod:`sys`, and :mod:`exceptions`.  It also
+initializes the module search path (``sys.path``).
+
+.. index:: single: PySys_SetArgv()
+
+:cfunc:`Py_Initialize` does not set the "script argument list"  (``sys.argv``).
+If this variable is needed by Python code that  will be executed later, it must
+be set explicitly with a call to  ``PySys_SetArgv(argc, argv)`` subsequent to
+the call to :cfunc:`Py_Initialize`.
+
+On most systems (in particular, on Unix and Windows, although the details are
+slightly different), :cfunc:`Py_Initialize` calculates the module search path
+based upon its best guess for the location of the standard Python interpreter
+executable, assuming that the Python library is found in a fixed location
+relative to the Python interpreter executable.  In particular, it looks for a
+directory named :file:`lib/python{X.Y}` relative to the parent directory
+where the executable named :file:`python` is found on the shell command search
+path (the environment variable :envvar:`PATH`).
+
+For instance, if the Python executable is found in
+:file:`/usr/local/bin/python`, it will assume that the libraries are in
+:file:`/usr/local/lib/python{X.Y}`.  (In fact, this particular path is also
+the "fallback" location, used when no executable file named :file:`python` is
+found along :envvar:`PATH`.)  The user can override this behavior by setting the
+environment variable :envvar:`PYTHONHOME`, or insert additional directories in
+front of the standard path by setting :envvar:`PYTHONPATH`.
+
+.. index::
+   single: Py_SetProgramName()
+   single: Py_GetPath()
+   single: Py_GetPrefix()
+   single: Py_GetExecPrefix()
+   single: Py_GetProgramFullPath()
+
+The embedding application can steer the search by calling
+``Py_SetProgramName(file)`` *before* calling  :cfunc:`Py_Initialize`.  Note that
+:envvar:`PYTHONHOME` still overrides this and :envvar:`PYTHONPATH` is still
+inserted in front of the standard path.  An application that requires total
+control has to provide its own implementation of :cfunc:`Py_GetPath`,
+:cfunc:`Py_GetPrefix`, :cfunc:`Py_GetExecPrefix`, and
+:cfunc:`Py_GetProgramFullPath` (all defined in :file:`Modules/getpath.c`).
+
+.. index:: single: Py_IsInitialized()
+
+Sometimes, it is desirable to "uninitialize" Python.  For instance,  the
+application may want to start over (make another call to
+:cfunc:`Py_Initialize`) or the application is simply done with its  use of
+Python and wants to free memory allocated by Python.  This can be accomplished
+by calling :cfunc:`Py_Finalize`.  The function :cfunc:`Py_IsInitialized` returns
+true if Python is currently in the initialized state.  More information about
+these functions is given in a later chapter. Notice that :cfunc:`Py_Finalize`
+does *not* free all memory allocated by the Python interpreter, e.g. memory
+allocated by extension modules currently cannot be released.
+
+
+.. _api-debugging:
+
+Debugging Builds
+================
+
+Python can be built with several macros to enable extra checks of the
+interpreter and extension modules.  These checks tend to add a large amount of
+overhead to the runtime so they are not enabled by default.
+
+A full list of the various types of debugging builds is in the file
+:file:`Misc/SpecialBuilds.txt` in the Python source distribution. Builds are
+available that support tracing of reference counts, debugging the memory
+allocator, or low-level profiling of the main interpreter loop.  Only the most
+frequently-used builds will be described in the remainder of this section.
+
+Compiling the interpreter with the :cmacro:`Py_DEBUG` macro defined produces
+what is generally meant by "a debug build" of Python. :cmacro:`Py_DEBUG` is
+enabled in the Unix build by adding :option:`--with-pydebug` to the
+:file:`configure` command.  It is also implied by the presence of the
+not-Python-specific :cmacro:`_DEBUG` macro.  When :cmacro:`Py_DEBUG` is enabled
+in the Unix build, compiler optimization is disabled.
+
+In addition to the reference count debugging described below, the following
+extra checks are performed:
+
+* Extra checks are added to the object allocator.
+
+* Extra checks are added to the parser and compiler.
+
+* Downcasts from wide types to narrow types are checked for loss of information.
+
+* A number of assertions are added to the dictionary and set implementations.
+  In addition, the set object acquires a :meth:`test_c_api` method.
+
+* Sanity checks of the input arguments are added to frame creation.
+
+* The storage for long ints is initialized with a known invalid pattern to catch
+  reference to uninitialized digits.
+
+* Low-level tracing and extra exception checking are added to the runtime
+  virtual machine.
+
+* Extra checks are added to the memory arena implementation.
+
+* Extra debugging is added to the thread module.
+
+There may be additional checks not mentioned here.
+
+Defining :cmacro:`Py_TRACE_REFS` enables reference tracing.  When defined, a
+circular doubly linked list of active objects is maintained by adding two extra
+fields to every :ctype:`PyObject`.  Total allocations are tracked as well.  Upon
+exit, all existing references are printed.  (In interactive mode this happens
+after every statement run by the interpreter.)  Implied by :cmacro:`Py_DEBUG`.
+
+Please refer to :file:`Misc/SpecialBuilds.txt` in the Python source distribution
+for more detailed information.
+
diff --git a/Doc/c-api/memory.rst b/Doc/c-api/memory.rst
new file mode 100644
index 0000000..1dcb115
--- /dev/null
+++ b/Doc/c-api/memory.rst
@@ -0,0 +1,207 @@
+.. highlightlang:: c
+
+
+.. _memory:
+
+*****************
+Memory Management
+*****************
+
+.. sectionauthor:: Vladimir Marangozov <Vladimir.Marangozov@inrialpes.fr>
+
+
+
+.. _memoryoverview:
+
+Overview
+========
+
+Memory management in Python involves a private heap containing all Python
+objects and data structures. The management of this private heap is ensured
+internally by the *Python memory manager*.  The Python memory manager has
+different components which deal with various dynamic storage management aspects,
+like sharing, segmentation, preallocation or caching.
+
+At the lowest level, a raw memory allocator ensures that there is enough room in
+the private heap for storing all Python-related data by interacting with the
+memory manager of the operating system. On top of the raw memory allocator,
+several object-specific allocators operate on the same heap and implement
+distinct memory management policies adapted to the peculiarities of every object
+type. For example, integer objects are managed differently within the heap than
+strings, tuples or dictionaries because integers imply different storage
+requirements and speed/space tradeoffs. The Python memory manager thus delegates
+some of the work to the object-specific allocators, but ensures that the latter
+operate within the bounds of the private heap.
+
+It is important to understand that the management of the Python heap is
+performed by the interpreter itself and that the user has no control over it,
+even if she regularly manipulates object pointers to memory blocks inside that
+heap.  The allocation of heap space for Python objects and other internal
+buffers is performed on demand by the Python memory manager through the Python/C
+API functions listed in this document.
+
+.. index::
+   single: malloc()
+   single: calloc()
+   single: realloc()
+   single: free()
+
+To avoid memory corruption, extension writers should never try to operate on
+Python objects with the functions exported by the C library: :cfunc:`malloc`,
+:cfunc:`calloc`, :cfunc:`realloc` and :cfunc:`free`.  This will result in  mixed
+calls between the C allocator and the Python memory manager with fatal
+consequences, because they implement different algorithms and operate on
+different heaps.  However, one may safely allocate and release memory blocks
+with the C library allocator for individual purposes, as shown in the following
+example::
+
+   PyObject *res;
+   char *buf = (char *) malloc(BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   ...Do some I/O operation involving buf...
+   res = PyString_FromString(buf);
+   free(buf); /* malloc'ed */
+   return res;
+
+In this example, the memory request for the I/O buffer is handled by the C
+library allocator. The Python memory manager is involved only in the allocation
+of the string object returned as a result.
+
+In most situations, however, it is recommended to allocate memory from the
+Python heap specifically because the latter is under control of the Python
+memory manager. For example, this is required when the interpreter is extended
+with new object types written in C. Another reason for using the Python heap is
+the desire to *inform* the Python memory manager about the memory needs of the
+extension module. Even when the requested memory is used exclusively for
+internal, highly-specific purposes, delegating all memory requests to the Python
+memory manager causes the interpreter to have a more accurate image of its
+memory footprint as a whole. Consequently, under certain circumstances, the
+Python memory manager may or may not trigger appropriate actions, like garbage
+collection, memory compaction or other preventive procedures. Note that by using
+the C library allocator as shown in the previous example, the allocated memory
+for the I/O buffer escapes completely the Python memory manager.
+
+
+.. _memoryinterface:
+
+Memory Interface
+================
+
+The following function sets, modeled after the ANSI C standard, but specifying
+behavior when requesting zero bytes, are available for allocating and releasing
+memory from the Python heap:
+
+
+.. cfunction:: void* PyMem_Malloc(size_t n)
+
+   Allocates *n* bytes and returns a pointer of type :ctype:`void\*` to the
+   allocated memory, or *NULL* if the request fails. Requesting zero bytes returns
+   a distinct non-*NULL* pointer if possible, as if :cfunc:`PyMem_Malloc(1)` had
+   been called instead. The memory will not have been initialized in any way.
+
+
+.. cfunction:: void* PyMem_Realloc(void *p, size_t n)
+
+   Resizes the memory block pointed to by *p* to *n* bytes. The contents will be
+   unchanged to the minimum of the old and the new sizes. If *p* is *NULL*, the
+   call is equivalent to :cfunc:`PyMem_Malloc(n)`; else if *n* is equal to zero,
+   the memory block is resized but is not freed, and the returned pointer is
+   non-*NULL*.  Unless *p* is *NULL*, it must have been returned by a previous call
+   to :cfunc:`PyMem_Malloc` or :cfunc:`PyMem_Realloc`. If the request fails,
+   :cfunc:`PyMem_Realloc` returns *NULL* and *p* remains a valid pointer to the
+   previous memory area.
+
+
+.. cfunction:: void PyMem_Free(void *p)
+
+   Frees the memory block pointed to by *p*, which must have been returned by a
+   previous call to :cfunc:`PyMem_Malloc` or :cfunc:`PyMem_Realloc`.  Otherwise, or
+   if :cfunc:`PyMem_Free(p)` has been called before, undefined behavior occurs. If
+   *p* is *NULL*, no operation is performed.
+
+The following type-oriented macros are provided for convenience.  Note  that
+*TYPE* refers to any C type.
+
+
+.. cfunction:: TYPE* PyMem_New(TYPE, size_t n)
+
+   Same as :cfunc:`PyMem_Malloc`, but allocates ``(n * sizeof(TYPE))`` bytes of
+   memory.  Returns a pointer cast to :ctype:`TYPE\*`.  The memory will not have
+   been initialized in any way.
+
+
+.. cfunction:: TYPE* PyMem_Resize(void *p, TYPE, size_t n)
+
+   Same as :cfunc:`PyMem_Realloc`, but the memory block is resized to ``(n *
+   sizeof(TYPE))`` bytes.  Returns a pointer cast to :ctype:`TYPE\*`. On return,
+   *p* will be a pointer to the new memory area, or *NULL* in the event of failure.
+
+
+.. cfunction:: void PyMem_Del(void *p)
+
+   Same as :cfunc:`PyMem_Free`.
+
+In addition, the following macro sets are provided for calling the Python memory
+allocator directly, without involving the C API functions listed above. However,
+note that their use does not preserve binary compatibility across Python
+versions and is therefore deprecated in extension modules.
+
+:cfunc:`PyMem_MALLOC`, :cfunc:`PyMem_REALLOC`, :cfunc:`PyMem_FREE`.
+
+:cfunc:`PyMem_NEW`, :cfunc:`PyMem_RESIZE`, :cfunc:`PyMem_DEL`.
+
+
+.. _memoryexamples:
+
+Examples
+========
+
+Here is the example from section :ref:`memoryoverview`, rewritten so that the
+I/O buffer is allocated from the Python heap by using the first function set::
+
+   PyObject *res;
+   char *buf = (char *) PyMem_Malloc(BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   /* ...Do some I/O operation involving buf... */
+   res = PyString_FromString(buf);
+   PyMem_Free(buf); /* allocated with PyMem_Malloc */
+   return res;
+
+The same code using the type-oriented function set::
+
+   PyObject *res;
+   char *buf = PyMem_New(char, BUFSIZ); /* for I/O */
+
+   if (buf == NULL)
+       return PyErr_NoMemory();
+   /* ...Do some I/O operation involving buf... */
+   res = PyString_FromString(buf);
+   PyMem_Del(buf); /* allocated with PyMem_New */
+   return res;
+
+Note that in the two examples above, the buffer is always manipulated via
+functions belonging to the same set. Indeed, it is required to use the same
+memory API family for a given memory block, so that the risk of mixing different
+allocators is reduced to a minimum. The following code sequence contains two
+errors, one of which is labeled as *fatal* because it mixes two different
+allocators operating on different heaps. ::
+
+   char *buf1 = PyMem_New(char, BUFSIZ);
+   char *buf2 = (char *) malloc(BUFSIZ);
+   char *buf3 = (char *) PyMem_Malloc(BUFSIZ);
+   ...
+   PyMem_Del(buf3);  /* Wrong -- should be PyMem_Free() */
+   free(buf2);       /* Right -- allocated via malloc() */
+   free(buf1);       /* Fatal -- should be PyMem_Del()  */
+
+In addition to the functions aimed at handling raw memory blocks from the Python
+heap, objects in Python are allocated and released with :cfunc:`PyObject_New`,
+:cfunc:`PyObject_NewVar` and :cfunc:`PyObject_Del`.
+
+These will be explained in the next chapter on defining and implementing new
+object types in C.
+
diff --git a/Doc/c-api/newtypes.rst b/Doc/c-api/newtypes.rst
new file mode 100644
index 0000000..5933f99
--- /dev/null
+++ b/Doc/c-api/newtypes.rst
@@ -0,0 +1,1740 @@
+.. highlightlang:: c
+
+
+.. _newtypes:
+
+*****************************
+Object Implementation Support
+*****************************
+
+This chapter describes the functions, types, and macros used when defining new
+object types.
+
+
+.. _allocating-objects:
+
+Allocating Objects on the Heap
+==============================
+
+
+.. cfunction:: PyObject* _PyObject_New(PyTypeObject *type)
+
+
+.. cfunction:: PyVarObject* _PyObject_NewVar(PyTypeObject *type, Py_ssize_t size)
+
+
+.. cfunction:: void _PyObject_Del(PyObject *op)
+
+
+.. cfunction:: PyObject* PyObject_Init(PyObject *op, PyTypeObject *type)
+
+   Initialize a newly-allocated object *op* with its type and initial reference.
+   Returns the initialized object.  If *type* indicates that the object
+   participates in the cyclic garbage detector, it is added to the detector's set
+   of observed objects. Other fields of the object are not affected.
+
+
+.. cfunction:: PyVarObject* PyObject_InitVar(PyVarObject *op, PyTypeObject *type, Py_ssize_t size)
+
+   This does everything :cfunc:`PyObject_Init` does, and also initializes the
+   length information for a variable-size object.
+
+
+.. cfunction:: TYPE* PyObject_New(TYPE, PyTypeObject *type)
+
+   Allocate a new Python object using the C structure type *TYPE* and the Python
+   type object *type*.  Fields not defined by the Python object header are not
+   initialized; the object's reference count will be one.  The size of the memory
+   allocation is determined from the :attr:`tp_basicsize` field of the type object.
+
+
+.. cfunction:: TYPE* PyObject_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
+
+   Allocate a new Python object using the C structure type *TYPE* and the Python
+   type object *type*.  Fields not defined by the Python object header are not
+   initialized.  The allocated memory allows for the *TYPE* structure plus *size*
+   fields of the size given by the :attr:`tp_itemsize` field of *type*.  This is
+   useful for implementing objects like tuples, which are able to determine their
+   size at construction time.  Embedding the array of fields into the same
+   allocation decreases the number of allocations, improving the memory management
+   efficiency.
+
+
+.. cfunction:: void PyObject_Del(PyObject *op)
+
+   Releases memory allocated to an object using :cfunc:`PyObject_New` or
+   :cfunc:`PyObject_NewVar`.  This is normally called from the :attr:`tp_dealloc`
+   handler specified in the object's type.  The fields of the object should not be
+   accessed after this call as the memory is no longer a valid Python object.
+
+
+.. cfunction:: PyObject* Py_InitModule(char *name, PyMethodDef *methods)
+
+   Create a new module object based on a name and table of functions, returning the
+   new module object.
+
+   .. versionchanged:: 2.3
+      Older versions of Python did not support *NULL* as the value for the *methods*
+      argument.
+
+
+.. cfunction:: PyObject* Py_InitModule3(char *name, PyMethodDef *methods, char *doc)
+
+   Create a new module object based on a name and table of functions, returning the
+   new module object.  If *doc* is non-*NULL*, it will be used to define the
+   docstring for the module.
+
+   .. versionchanged:: 2.3
+      Older versions of Python did not support *NULL* as the value for the *methods*
+      argument.
+
+
+.. cfunction:: PyObject* Py_InitModule4(char *name, PyMethodDef *methods, char *doc, PyObject *self, int apiver)
+
+   Create a new module object based on a name and table of functions, returning the
+   new module object.  If *doc* is non-*NULL*, it will be used to define the
+   docstring for the module.  If *self* is non-*NULL*, it will passed to the
+   functions of the module as their (otherwise *NULL*) first parameter.  (This was
+   added as an experimental feature, and there are no known uses in the current
+   version of Python.)  For *apiver*, the only value which should be passed is
+   defined by the constant :const:`PYTHON_API_VERSION`.
+
+   .. note::
+
+      Most uses of this function should probably be using the :cfunc:`Py_InitModule3`
+      instead; only use this if you are sure you need it.
+
+   .. versionchanged:: 2.3
+      Older versions of Python did not support *NULL* as the value for the *methods*
+      argument.
+
+
+.. cvar:: PyObject _Py_NoneStruct
+
+   Object which is visible in Python as ``None``.  This should only be accessed
+   using the ``Py_None`` macro, which evaluates to a pointer to this object.
+
+
+.. _common-structs:
+
+Common Object Structures
+========================
+
+There are a large number of structures which are used in the definition of
+object types for Python.  This section describes these structures and how they
+are used.
+
+All Python objects ultimately share a small number of fields at the beginning of
+the object's representation in memory.  These are represented by the
+:ctype:`PyObject` and :ctype:`PyVarObject` types, which are defined, in turn, by
+the expansions of some macros also used, whether directly or indirectly, in the
+definition of all other Python objects.
+
+
+.. ctype:: PyObject
+
+   All object types are extensions of this type.  This is a type which contains the
+   information Python needs to treat a pointer to an object as an object.  In a
+   normal "release" build, it contains only the objects reference count and a
+   pointer to the corresponding type object.  It corresponds to the fields defined
+   by the expansion of the ``PyObject_HEAD`` macro.
+
+
+.. ctype:: PyVarObject
+
+   This is an extension of :ctype:`PyObject` that adds the :attr:`ob_size` field.
+   This is only used for objects that have some notion of *length*.  This type does
+   not often appear in the Python/C API.  It corresponds to the fields defined by
+   the expansion of the ``PyObject_VAR_HEAD`` macro.
+
+These macros are used in the definition of :ctype:`PyObject` and
+:ctype:`PyVarObject`:
+
+
+.. cmacro:: PyObject_HEAD
+
+   This is a macro which expands to the declarations of the fields of the
+   :ctype:`PyObject` type; it is used when declaring new types which represent
+   objects without a varying length.  The specific fields it expands to depend on
+   the definition of :cmacro:`Py_TRACE_REFS`.  By default, that macro is not
+   defined, and :cmacro:`PyObject_HEAD` expands to::
+
+      Py_ssize_t ob_refcnt;
+      PyTypeObject *ob_type;
+
+   When :cmacro:`Py_TRACE_REFS` is defined, it expands to::
+
+      PyObject *_ob_next, *_ob_prev;
+      Py_ssize_t ob_refcnt;
+      PyTypeObject *ob_type;
+
+
+.. cmacro:: PyObject_VAR_HEAD
+
+   This is a macro which expands to the declarations of the fields of the
+   :ctype:`PyVarObject` type; it is used when declaring new types which represent
+   objects with a length that varies from instance to instance.  This macro always
+   expands to::
+
+      PyObject_HEAD
+      Py_ssize_t ob_size;
+
+   Note that :cmacro:`PyObject_HEAD` is part of the expansion, and that its own
+   expansion varies depending on the definition of :cmacro:`Py_TRACE_REFS`.
+
+PyObject_HEAD_INIT
+
+
+.. ctype:: PyCFunction
+
+   Type of the functions used to implement most Python callables in C. Functions of
+   this type take two :ctype:`PyObject\*` parameters and return one such value.  If
+   the return value is *NULL*, an exception shall have been set.  If not *NULL*,
+   the return value is interpreted as the return value of the function as exposed
+   in Python.  The function must return a new reference.
+
+
+.. ctype:: PyMethodDef
+
+   Structure used to describe a method of an extension type.  This structure has
+   four fields:
+
+   +------------------+-------------+-------------------------------+
+   | Field            | C Type      | Meaning                       |
+   +==================+=============+===============================+
+   | :attr:`ml_name`  | char \*     | name of the method            |
+   +------------------+-------------+-------------------------------+
+   | :attr:`ml_meth`  | PyCFunction | pointer to the C              |
+   |                  |             | implementation                |
+   +------------------+-------------+-------------------------------+
+   | :attr:`ml_flags` | int         | flag bits indicating how the  |
+   |                  |             | call should be constructed    |
+   +------------------+-------------+-------------------------------+
+   | :attr:`ml_doc`   | char \*     | points to the contents of the |
+   |                  |             | docstring                     |
+   +------------------+-------------+-------------------------------+
+
+The :attr:`ml_meth` is a C function pointer.  The functions may be of different
+types, but they always return :ctype:`PyObject\*`.  If the function is not of
+the :ctype:`PyCFunction`, the compiler will require a cast in the method table.
+Even though :ctype:`PyCFunction` defines the first parameter as
+:ctype:`PyObject\*`, it is common that the method implementation uses a the
+specific C type of the *self* object.
+
+The :attr:`ml_flags` field is a bitfield which can include the following flags.
+The individual flags indicate either a calling convention or a binding
+convention.  Of the calling convention flags, only :const:`METH_VARARGS` and
+:const:`METH_KEYWORDS` can be combined (but note that :const:`METH_KEYWORDS`
+alone is equivalent to ``METH_VARARGS | METH_KEYWORDS``). Any of the calling
+convention flags can be combined with a binding flag.
+
+
+.. data:: METH_VARARGS
+
+   This is the typical calling convention, where the methods have the type
+   :ctype:`PyCFunction`. The function expects two :ctype:`PyObject\*` values.  The
+   first one is the *self* object for methods; for module functions, it has the
+   value given to :cfunc:`Py_InitModule4` (or *NULL* if :cfunc:`Py_InitModule` was
+   used).  The second parameter (often called *args*) is a tuple object
+   representing all arguments. This parameter is typically processed using
+   :cfunc:`PyArg_ParseTuple` or :cfunc:`PyArg_UnpackTuple`.
+
+
+.. data:: METH_KEYWORDS
+
+   Methods with these flags must be of type :ctype:`PyCFunctionWithKeywords`.  The
+   function expects three parameters: *self*, *args*, and a dictionary of all the
+   keyword arguments.  The flag is typically combined with :const:`METH_VARARGS`,
+   and the parameters are typically processed using
+   :cfunc:`PyArg_ParseTupleAndKeywords`.
+
+
+.. data:: METH_NOARGS
+
+   Methods without parameters don't need to check whether arguments are given if
+   they are listed with the :const:`METH_NOARGS` flag.  They need to be of type
+   :ctype:`PyCFunction`.  When used with object methods, the first parameter is
+   typically named ``self`` and will hold a reference to the object instance.  In
+   all cases the second parameter will be *NULL*.
+
+
+.. data:: METH_O
+
+   Methods with a single object argument can be listed with the :const:`METH_O`
+   flag, instead of invoking :cfunc:`PyArg_ParseTuple` with a ``"O"`` argument.
+   They have the type :ctype:`PyCFunction`, with the *self* parameter, and a
+   :ctype:`PyObject\*` parameter representing the single argument.
+
+
+.. data:: METH_OLDARGS
+
+   This calling convention is deprecated.  The method must be of type
+   :ctype:`PyCFunction`.  The second argument is *NULL* if no arguments are given,
+   a single object if exactly one argument is given, and a tuple of objects if more
+   than one argument is given.  There is no way for a function using this
+   convention to distinguish between a call with multiple arguments and a call with
+   a tuple as the only argument.
+
+These two constants are not used to indicate the calling convention but the
+binding when use with methods of classes.  These may not be used for functions
+defined for modules.  At most one of these flags may be set for any given
+method.
+
+
+.. data:: METH_CLASS
+
+   .. index:: builtin: classmethod
+
+   The method will be passed the type object as the first parameter rather than an
+   instance of the type.  This is used to create *class methods*, similar to what
+   is created when using the :func:`classmethod` built-in function.
+
+   .. versionadded:: 2.3
+
+
+.. data:: METH_STATIC
+
+   .. index:: builtin: staticmethod
+
+   The method will be passed *NULL* as the first parameter rather than an instance
+   of the type.  This is used to create *static methods*, similar to what is
+   created when using the :func:`staticmethod` built-in function.
+
+   .. versionadded:: 2.3
+
+One other constant controls whether a method is loaded in place of another
+definition with the same method name.
+
+
+.. data:: METH_COEXIST
+
+   The method will be loaded in place of existing definitions.  Without
+   *METH_COEXIST*, the default is to skip repeated definitions.  Since slot
+   wrappers are loaded before the method table, the existence of a *sq_contains*
+   slot, for example, would generate a wrapped method named :meth:`__contains__`
+   and preclude the loading of a corresponding PyCFunction with the same name.
+   With the flag defined, the PyCFunction will be loaded in place of the wrapper
+   object and will co-exist with the slot.  This is helpful because calls to
+   PyCFunctions are optimized more than wrapper object calls.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: PyObject* Py_FindMethod(PyMethodDef table[], PyObject *ob, char *name)
+
+   Return a bound method object for an extension type implemented in C.  This can
+   be useful in the implementation of a :attr:`tp_getattro` or :attr:`tp_getattr`
+   handler that does not use the :cfunc:`PyObject_GenericGetAttr` function.
+
+
+.. _type-structs:
+
+Type Objects
+============
+
+Perhaps one of the most important structures of the Python object system is the
+structure that defines a new type: the :ctype:`PyTypeObject` structure.  Type
+objects can be handled using any of the :cfunc:`PyObject_\*` or
+:cfunc:`PyType_\*` functions, but do not offer much that's interesting to most
+Python applications. These objects are fundamental to how objects behave, so
+they are very important to the interpreter itself and to any extension module
+that implements new types.
+
+Type objects are fairly large compared to most of the standard types. The reason
+for the size is that each type object stores a large number of values, mostly C
+function pointers, each of which implements a small part of the type's
+functionality.  The fields of the type object are examined in detail in this
+section.  The fields will be described in the order in which they occur in the
+structure.
+
+Typedefs: unaryfunc, binaryfunc, ternaryfunc, inquiry, coercion, intargfunc,
+intintargfunc, intobjargproc, intintobjargproc, objobjargproc, destructor,
+freefunc, printfunc, getattrfunc, getattrofunc, setattrfunc, setattrofunc,
+cmpfunc, reprfunc, hashfunc
+
+The structure definition for :ctype:`PyTypeObject` can be found in
+:file:`Include/object.h`.  For convenience of reference, this repeats the
+definition found there:
+
+.. literalinclude:: ../includes/typestruct.h
+
+
+The type object structure extends the :ctype:`PyVarObject` structure. The
+:attr:`ob_size` field is used for dynamic types (created by  :func:`type_new`,
+usually called from a class statement). Note that :cdata:`PyType_Type` (the
+metatype) initializes :attr:`tp_itemsize`, which means that its instances (i.e.
+type objects) *must* have the :attr:`ob_size` field.
+
+
+.. cmember:: PyObject* PyObject._ob_next
+             PyObject* PyObject._ob_prev
+
+   These fields are only present when the macro ``Py_TRACE_REFS`` is defined.
+   Their initialization to *NULL* is taken care of by the ``PyObject_HEAD_INIT``
+   macro.  For statically allocated objects, these fields always remain *NULL*.
+   For dynamically allocated objects, these two fields are used to link the object
+   into a doubly-linked list of *all* live objects on the heap.  This could be used
+   for various debugging purposes; currently the only use is to print the objects
+   that are still alive at the end of a run when the environment variable
+   :envvar:`PYTHONDUMPREFS` is set.
+
+   These fields are not inherited by subtypes.
+
+
+.. cmember:: Py_ssize_t PyObject.ob_refcnt
+
+   This is the type object's reference count, initialized to ``1`` by the
+   ``PyObject_HEAD_INIT`` macro.  Note that for statically allocated type objects,
+   the type's instances (objects whose :attr:`ob_type` points back to the type) do
+   *not* count as references.  But for dynamically allocated type objects, the
+   instances *do* count as references.
+
+   This field is not inherited by subtypes.
+
+
+.. cmember:: PyTypeObject* PyObject.ob_type
+
+   This is the type's type, in other words its metatype.  It is initialized by the
+   argument to the ``PyObject_HEAD_INIT`` macro, and its value should normally be
+   ``&PyType_Type``.  However, for dynamically loadable extension modules that must
+   be usable on Windows (at least), the compiler complains that this is not a valid
+   initializer.  Therefore, the convention is to pass *NULL* to the
+   ``PyObject_HEAD_INIT`` macro and to initialize this field explicitly at the
+   start of the module's initialization function, before doing anything else.  This
+   is typically done like this::
+
+      Foo_Type.ob_type = &PyType_Type;
+
+   This should be done before any instances of the type are created.
+   :cfunc:`PyType_Ready` checks if :attr:`ob_type` is *NULL*, and if so,
+   initializes it: in Python 2.2, it is set to ``&PyType_Type``; in Python 2.2.1
+   and later it is initialized to the :attr:`ob_type` field of the base class.
+   :cfunc:`PyType_Ready` will not change this field if it is non-zero.
+
+   In Python 2.2, this field is not inherited by subtypes.  In 2.2.1, and in 2.3
+   and beyond, it is inherited by subtypes.
+
+
+.. cmember:: Py_ssize_t PyVarObject.ob_size
+
+   For statically allocated type objects, this should be initialized to zero.  For
+   dynamically allocated type objects, this field has a special internal meaning.
+
+   This field is not inherited by subtypes.
+
+
+.. cmember:: char* PyTypeObject.tp_name
+
+   Pointer to a NUL-terminated string containing the name of the type. For types
+   that are accessible as module globals, the string should be the full module
+   name, followed by a dot, followed by the type name; for built-in types, it
+   should be just the type name.  If the module is a submodule of a package, the
+   full package name is part of the full module name.  For example, a type named
+   :class:`T` defined in module :mod:`M` in subpackage :mod:`Q` in package :mod:`P`
+   should have the :attr:`tp_name` initializer ``"P.Q.M.T"``.
+
+   For dynamically allocated type objects, this should just be the type name, and
+   the module name explicitly stored in the type dict as the value for key
+   ``'__module__'``.
+
+   For statically allocated type objects, the tp_name field should contain a dot.
+   Everything before the last dot is made accessible as the :attr:`__module__`
+   attribute, and everything after the last dot is made accessible as the
+   :attr:`__name__` attribute.
+
+   If no dot is present, the entire :attr:`tp_name` field is made accessible as the
+   :attr:`__name__` attribute, and the :attr:`__module__` attribute is undefined
+   (unless explicitly set in the dictionary, as explained above).  This means your
+   type will be impossible to pickle.
+
+   This field is not inherited by subtypes.
+
+
+.. cmember:: Py_ssize_t PyTypeObject.tp_basicsize
+             Py_ssize_t PyTypeObject.tp_itemsize
+
+   These fields allow calculating the size in bytes of instances of the type.
+
+   There are two kinds of types: types with fixed-length instances have a zero
+   :attr:`tp_itemsize` field, types with variable-length instances have a non-zero
+   :attr:`tp_itemsize` field.  For a type with fixed-length instances, all
+   instances have the same size, given in :attr:`tp_basicsize`.
+
+   For a type with variable-length instances, the instances must have an
+   :attr:`ob_size` field, and the instance size is :attr:`tp_basicsize` plus N
+   times :attr:`tp_itemsize`, where N is the "length" of the object.  The value of
+   N is typically stored in the instance's :attr:`ob_size` field.  There are
+   exceptions:  for example, long ints use a negative :attr:`ob_size` to indicate a
+   negative number, and N is ``abs(ob_size)`` there.  Also, the presence of an
+   :attr:`ob_size` field in the instance layout doesn't mean that the instance
+   structure is variable-length (for example, the structure for the list type has
+   fixed-length instances, yet those instances have a meaningful :attr:`ob_size`
+   field).
+
+   The basic size includes the fields in the instance declared by the macro
+   :cmacro:`PyObject_HEAD` or :cmacro:`PyObject_VAR_HEAD` (whichever is used to
+   declare the instance struct) and this in turn includes the :attr:`_ob_prev` and
+   :attr:`_ob_next` fields if they are present.  This means that the only correct
+   way to get an initializer for the :attr:`tp_basicsize` is to use the
+   :keyword:`sizeof` operator on the struct used to declare the instance layout.
+   The basic size does not include the GC header size (this is new in Python 2.2;
+   in 2.1 and 2.0, the GC header size was included in :attr:`tp_basicsize`).
+
+   These fields are inherited separately by subtypes.  If the base type has a
+   non-zero :attr:`tp_itemsize`, it is generally not safe to set
+   :attr:`tp_itemsize` to a different non-zero value in a subtype (though this
+   depends on the implementation of the base type).
+
+   A note about alignment: if the variable items require a particular alignment,
+   this should be taken care of by the value of :attr:`tp_basicsize`.  Example:
+   suppose a type implements an array of ``double``. :attr:`tp_itemsize` is
+   ``sizeof(double)``. It is the programmer's responsibility that
+   :attr:`tp_basicsize` is a multiple of ``sizeof(double)`` (assuming this is the
+   alignment requirement for ``double``).
+
+
+.. cmember:: destructor PyTypeObject.tp_dealloc
+
+   A pointer to the instance destructor function.  This function must be defined
+   unless the type guarantees that its instances will never be deallocated (as is
+   the case for the singletons ``None`` and ``Ellipsis``).
+
+   The destructor function is called by the :cfunc:`Py_DECREF` and
+   :cfunc:`Py_XDECREF` macros when the new reference count is zero.  At this point,
+   the instance is still in existence, but there are no references to it.  The
+   destructor function should free all references which the instance owns, free all
+   memory buffers owned by the instance (using the freeing function corresponding
+   to the allocation function used to allocate the buffer), and finally (as its
+   last action) call the type's :attr:`tp_free` function.  If the type is not
+   subtypable (doesn't have the :const:`Py_TPFLAGS_BASETYPE` flag bit set), it is
+   permissible to call the object deallocator directly instead of via
+   :attr:`tp_free`.  The object deallocator should be the one used to allocate the
+   instance; this is normally :cfunc:`PyObject_Del` if the instance was allocated
+   using :cfunc:`PyObject_New` or :cfunc:`PyObject_VarNew`, or
+   :cfunc:`PyObject_GC_Del` if the instance was allocated using
+   :cfunc:`PyObject_GC_New` or :cfunc:`PyObject_GC_VarNew`.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: printfunc PyTypeObject.tp_print
+
+   An optional pointer to the instance print function.
+
+   The print function is only called when the instance is printed to a *real* file;
+   when it is printed to a pseudo-file (like a :class:`StringIO` instance), the
+   instance's :attr:`tp_repr` or :attr:`tp_str` function is called to convert it to
+   a string.  These are also called when the type's :attr:`tp_print` field is
+   *NULL*.  A type should never implement :attr:`tp_print` in a way that produces
+   different output than :attr:`tp_repr` or :attr:`tp_str` would.
+
+   The print function is called with the same signature as :cfunc:`PyObject_Print`:
+   ``int tp_print(PyObject *self, FILE *file, int flags)``.  The *self* argument is
+   the instance to be printed.  The *file* argument is the stdio file to which it
+   is to be printed.  The *flags* argument is composed of flag bits. The only flag
+   bit currently defined is :const:`Py_PRINT_RAW`. When the :const:`Py_PRINT_RAW`
+   flag bit is set, the instance should be printed the same way as :attr:`tp_str`
+   would format it; when the :const:`Py_PRINT_RAW` flag bit is clear, the instance
+   should be printed the same was as :attr:`tp_repr` would format it. It should
+   return ``-1`` and set an exception condition when an error occurred during the
+   comparison.
+
+   It is possible that the :attr:`tp_print` field will be deprecated. In any case,
+   it is recommended not to define :attr:`tp_print`, but instead to rely on
+   :attr:`tp_repr` and :attr:`tp_str` for printing.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: getattrfunc PyTypeObject.tp_getattr
+
+   An optional pointer to the get-attribute-string function.
+
+   This field is deprecated.  When it is defined, it should point to a function
+   that acts the same as the :attr:`tp_getattro` function, but taking a C string
+   instead of a Python string object to give the attribute name.  The signature is
+   the same as for :cfunc:`PyObject_GetAttrString`.
+
+   This field is inherited by subtypes together with :attr:`tp_getattro`: a subtype
+   inherits both :attr:`tp_getattr` and :attr:`tp_getattro` from its base type when
+   the subtype's :attr:`tp_getattr` and :attr:`tp_getattro` are both *NULL*.
+
+
+.. cmember:: setattrfunc PyTypeObject.tp_setattr
+
+   An optional pointer to the set-attribute-string function.
+
+   This field is deprecated.  When it is defined, it should point to a function
+   that acts the same as the :attr:`tp_setattro` function, but taking a C string
+   instead of a Python string object to give the attribute name.  The signature is
+   the same as for :cfunc:`PyObject_SetAttrString`.
+
+   This field is inherited by subtypes together with :attr:`tp_setattro`: a subtype
+   inherits both :attr:`tp_setattr` and :attr:`tp_setattro` from its base type when
+   the subtype's :attr:`tp_setattr` and :attr:`tp_setattro` are both *NULL*.
+
+
+.. cmember:: cmpfunc PyTypeObject.tp_compare
+
+   An optional pointer to the three-way comparison function.
+
+   The signature is the same as for :cfunc:`PyObject_Compare`. The function should
+   return ``1`` if *self* greater than *other*, ``0`` if *self* is equal to
+   *other*, and ``-1`` if *self* less than *other*.  It should return ``-1`` and
+   set an exception condition when an error occurred during the comparison.
+
+   This field is inherited by subtypes together with :attr:`tp_richcompare` and
+   :attr:`tp_hash`: a subtypes inherits all three of :attr:`tp_compare`,
+   :attr:`tp_richcompare`, and :attr:`tp_hash` when the subtype's
+   :attr:`tp_compare`, :attr:`tp_richcompare`, and :attr:`tp_hash` are all *NULL*.
+
+
+.. cmember:: reprfunc PyTypeObject.tp_repr
+
+   .. index:: builtin: repr
+
+   An optional pointer to a function that implements the built-in function
+   :func:`repr`.
+
+   The signature is the same as for :cfunc:`PyObject_Repr`; it must return a string
+   or a Unicode object.  Ideally, this function should return a string that, when
+   passed to :func:`eval`, given a suitable environment, returns an object with the
+   same value.  If this is not feasible, it should return a string starting with
+   ``'<'`` and ending with ``'>'`` from which both the type and the value of the
+   object can be deduced.
+
+   When this field is not set, a string of the form ``<%s object at %p>`` is
+   returned, where ``%s`` is replaced by the type name, and ``%p`` by the object's
+   memory address.
+
+   This field is inherited by subtypes.
+
+.. cmember:: PyNumberMethods *tp_as_number;
+
+   XXX
+
+.. cmember:: PySequenceMethods *tp_as_sequence;
+
+   XXX
+
+.. cmember:: PyMappingMethods *tp_as_mapping;
+
+   XXX
+
+
+.. cmember:: hashfunc PyTypeObject.tp_hash
+
+   .. index:: builtin: hash
+
+   An optional pointer to a function that implements the built-in function
+   :func:`hash`.
+
+   The signature is the same as for :cfunc:`PyObject_Hash`; it must return a C
+   long.  The value ``-1`` should not be returned as a normal return value; when an
+   error occurs during the computation of the hash value, the function should set
+   an exception and return ``-1``.
+
+   When this field is not set, two possibilities exist: if the :attr:`tp_compare`
+   and :attr:`tp_richcompare` fields are both *NULL*, a default hash value based on
+   the object's address is returned; otherwise, a :exc:`TypeError` is raised.
+
+   This field is inherited by subtypes together with :attr:`tp_richcompare` and
+   :attr:`tp_compare`: a subtypes inherits all three of :attr:`tp_compare`,
+   :attr:`tp_richcompare`, and :attr:`tp_hash`, when the subtype's
+   :attr:`tp_compare`, :attr:`tp_richcompare` and :attr:`tp_hash` are all *NULL*.
+
+
+.. cmember:: ternaryfunc PyTypeObject.tp_call
+
+   An optional pointer to a function that implements calling the object.  This
+   should be *NULL* if the object is not callable.  The signature is the same as
+   for :cfunc:`PyObject_Call`.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: reprfunc PyTypeObject.tp_str
+
+   An optional pointer to a function that implements the built-in operation
+   :func:`str`.  (Note that :class:`str` is a type now, and :func:`str` calls the
+   constructor for that type.  This constructor calls :cfunc:`PyObject_Str` to do
+   the actual work, and :cfunc:`PyObject_Str` will call this handler.)
+
+   The signature is the same as for :cfunc:`PyObject_Str`; it must return a string
+   or a Unicode object.  This function should return a "friendly" string
+   representation of the object, as this is the representation that will be used by
+   the print statement.
+
+   When this field is not set, :cfunc:`PyObject_Repr` is called to return a string
+   representation.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: getattrofunc PyTypeObject.tp_getattro
+
+   An optional pointer to the get-attribute function.
+
+   The signature is the same as for :cfunc:`PyObject_GetAttr`.  It is usually
+   convenient to set this field to :cfunc:`PyObject_GenericGetAttr`, which
+   implements the normal way of looking for object attributes.
+
+   This field is inherited by subtypes together with :attr:`tp_getattr`: a subtype
+   inherits both :attr:`tp_getattr` and :attr:`tp_getattro` from its base type when
+   the subtype's :attr:`tp_getattr` and :attr:`tp_getattro` are both *NULL*.
+
+
+.. cmember:: setattrofunc PyTypeObject.tp_setattro
+
+   An optional pointer to the set-attribute function.
+
+   The signature is the same as for :cfunc:`PyObject_SetAttr`.  It is usually
+   convenient to set this field to :cfunc:`PyObject_GenericSetAttr`, which
+   implements the normal way of setting object attributes.
+
+   This field is inherited by subtypes together with :attr:`tp_setattr`: a subtype
+   inherits both :attr:`tp_setattr` and :attr:`tp_setattro` from its base type when
+   the subtype's :attr:`tp_setattr` and :attr:`tp_setattro` are both *NULL*.
+
+
+.. cmember:: PyBufferProcs* PyTypeObject.tp_as_buffer
+
+   Pointer to an additional structure that contains fields relevant only to objects
+   which implement the buffer interface.  These fields are documented in
+   :ref:`buffer-structs`.
+
+   The :attr:`tp_as_buffer` field is not inherited, but the contained fields are
+   inherited individually.
+
+
+.. cmember:: long PyTypeObject.tp_flags
+
+   This field is a bit mask of various flags.  Some flags indicate variant
+   semantics for certain situations; others are used to indicate that certain
+   fields in the type object (or in the extension structures referenced via
+   :attr:`tp_as_number`, :attr:`tp_as_sequence`, :attr:`tp_as_mapping`, and
+   :attr:`tp_as_buffer`) that were historically not always present are valid; if
+   such a flag bit is clear, the type fields it guards must not be accessed and
+   must be considered to have a zero or *NULL* value instead.
+
+   Inheritance of this field is complicated.  Most flag bits are inherited
+   individually, i.e. if the base type has a flag bit set, the subtype inherits
+   this flag bit.  The flag bits that pertain to extension structures are strictly
+   inherited if the extension structure is inherited, i.e. the base type's value of
+   the flag bit is copied into the subtype together with a pointer to the extension
+   structure.  The :const:`Py_TPFLAGS_HAVE_GC` flag bit is inherited together with
+   the :attr:`tp_traverse` and :attr:`tp_clear` fields, i.e. if the
+   :const:`Py_TPFLAGS_HAVE_GC` flag bit is clear in the subtype and the
+   :attr:`tp_traverse` and :attr:`tp_clear` fields in the subtype exist (as
+   indicated by the :const:`Py_TPFLAGS_HAVE_RICHCOMPARE` flag bit) and have *NULL*
+   values.
+
+   The following bit masks are currently defined; these can be or-ed together using
+   the ``|`` operator to form the value of the :attr:`tp_flags` field.  The macro
+   :cfunc:`PyType_HasFeature` takes a type and a flags value, *tp* and *f*, and
+   checks whether ``tp->tp_flags & f`` is non-zero.
+
+
+   .. data:: Py_TPFLAGS_HAVE_GETCHARBUFFER
+
+      If this bit is set, the :ctype:`PyBufferProcs` struct referenced by
+      :attr:`tp_as_buffer` has the :attr:`bf_getcharbuffer` field.
+
+
+   .. data:: Py_TPFLAGS_HAVE_SEQUENCE_IN
+
+      If this bit is set, the :ctype:`PySequenceMethods` struct referenced by
+      :attr:`tp_as_sequence` has the :attr:`sq_contains` field.
+
+
+   .. data:: Py_TPFLAGS_GC
+
+      This bit is obsolete.  The bit it used to name is no longer in use.  The symbol
+      is now defined as zero.
+
+
+   .. data:: Py_TPFLAGS_HAVE_INPLACEOPS
+
+      If this bit is set, the :ctype:`PySequenceMethods` struct referenced by
+      :attr:`tp_as_sequence` and the :ctype:`PyNumberMethods` structure referenced by
+      :attr:`tp_as_number` contain the fields for in-place operators. In particular,
+      this means that the :ctype:`PyNumberMethods` structure has the fields
+      :attr:`nb_inplace_add`, :attr:`nb_inplace_subtract`,
+      :attr:`nb_inplace_multiply`, :attr:`nb_inplace_divide`,
+      :attr:`nb_inplace_remainder`, :attr:`nb_inplace_power`,
+      :attr:`nb_inplace_lshift`, :attr:`nb_inplace_rshift`, :attr:`nb_inplace_and`,
+      :attr:`nb_inplace_xor`, and :attr:`nb_inplace_or`; and the
+      :ctype:`PySequenceMethods` struct has the fields :attr:`sq_inplace_concat` and
+      :attr:`sq_inplace_repeat`.
+
+
+   .. data:: Py_TPFLAGS_CHECKTYPES
+
+      If this bit is set, the binary and ternary operations in the
+      :ctype:`PyNumberMethods` structure referenced by :attr:`tp_as_number` accept
+      arguments of arbitrary object types, and do their own type conversions if
+      needed.  If this bit is clear, those operations require that all arguments have
+      the current type as their type, and the caller is supposed to perform a coercion
+      operation first.  This applies to :attr:`nb_add`, :attr:`nb_subtract`,
+      :attr:`nb_multiply`, :attr:`nb_divide`, :attr:`nb_remainder`, :attr:`nb_divmod`,
+      :attr:`nb_power`, :attr:`nb_lshift`, :attr:`nb_rshift`, :attr:`nb_and`,
+      :attr:`nb_xor`, and :attr:`nb_or`.
+
+
+   .. data:: Py_TPFLAGS_HAVE_RICHCOMPARE
+
+      If this bit is set, the type object has the :attr:`tp_richcompare` field, as
+      well as the :attr:`tp_traverse` and the :attr:`tp_clear` fields.
+
+
+   .. data:: Py_TPFLAGS_HAVE_WEAKREFS
+
+      If this bit is set, the :attr:`tp_weaklistoffset` field is defined.  Instances
+      of a type are weakly referenceable if the type's :attr:`tp_weaklistoffset` field
+      has a value greater than zero.
+
+
+   .. data:: Py_TPFLAGS_HAVE_ITER
+
+      If this bit is set, the type object has the :attr:`tp_iter` and
+      :attr:`tp_iternext` fields.
+
+
+   .. data:: Py_TPFLAGS_HAVE_CLASS
+
+      If this bit is set, the type object has several new fields defined starting in
+      Python 2.2: :attr:`tp_methods`, :attr:`tp_members`, :attr:`tp_getset`,
+      :attr:`tp_base`, :attr:`tp_dict`, :attr:`tp_descr_get`, :attr:`tp_descr_set`,
+      :attr:`tp_dictoffset`, :attr:`tp_init`, :attr:`tp_alloc`, :attr:`tp_new`,
+      :attr:`tp_free`, :attr:`tp_is_gc`, :attr:`tp_bases`, :attr:`tp_mro`,
+      :attr:`tp_cache`, :attr:`tp_subclasses`, and :attr:`tp_weaklist`.
+
+
+   .. data:: Py_TPFLAGS_HEAPTYPE
+
+      This bit is set when the type object itself is allocated on the heap.  In this
+      case, the :attr:`ob_type` field of its instances is considered a reference to
+      the type, and the type object is INCREF'ed when a new instance is created, and
+      DECREF'ed when an instance is destroyed (this does not apply to instances of
+      subtypes; only the type referenced by the instance's ob_type gets INCREF'ed or
+      DECREF'ed).
+
+
+   .. data:: Py_TPFLAGS_BASETYPE
+
+      This bit is set when the type can be used as the base type of another type.  If
+      this bit is clear, the type cannot be subtyped (similar to a "final" class in
+      Java).
+
+
+   .. data:: Py_TPFLAGS_READY
+
+      This bit is set when the type object has been fully initialized by
+      :cfunc:`PyType_Ready`.
+
+
+   .. data:: Py_TPFLAGS_READYING
+
+      This bit is set while :cfunc:`PyType_Ready` is in the process of initializing
+      the type object.
+
+
+   .. data:: Py_TPFLAGS_HAVE_GC
+
+      This bit is set when the object supports garbage collection.  If this bit
+      is set, instances must be created using :cfunc:`PyObject_GC_New` and
+      destroyed using :cfunc:`PyObject_GC_Del`.  More information in section
+      :ref:`supporting-cycle-detection`.  This bit also implies that the
+      GC-related fields :attr:`tp_traverse` and :attr:`tp_clear` are present in
+      the type object; but those fields also exist when
+      :const:`Py_TPFLAGS_HAVE_GC` is clear but
+      :const:`Py_TPFLAGS_HAVE_RICHCOMPARE` is set.
+
+
+   .. data:: Py_TPFLAGS_DEFAULT
+
+      This is a bitmask of all the bits that pertain to the existence of certain
+      fields in the type object and its extension structures. Currently, it includes
+      the following bits: :const:`Py_TPFLAGS_HAVE_GETCHARBUFFER`,
+      :const:`Py_TPFLAGS_HAVE_SEQUENCE_IN`, :const:`Py_TPFLAGS_HAVE_INPLACEOPS`,
+      :const:`Py_TPFLAGS_HAVE_RICHCOMPARE`, :const:`Py_TPFLAGS_HAVE_WEAKREFS`,
+      :const:`Py_TPFLAGS_HAVE_ITER`, and :const:`Py_TPFLAGS_HAVE_CLASS`.
+
+
+.. cmember:: char* PyTypeObject.tp_doc
+
+   An optional pointer to a NUL-terminated C string giving the docstring for this
+   type object.  This is exposed as the :attr:`__doc__` attribute on the type and
+   instances of the type.
+
+   This field is *not* inherited by subtypes.
+
+The following three fields only exist if the
+:const:`Py_TPFLAGS_HAVE_RICHCOMPARE` flag bit is set.
+
+
+.. cmember:: traverseproc PyTypeObject.tp_traverse
+
+   An optional pointer to a traversal function for the garbage collector.  This is
+   only used if the :const:`Py_TPFLAGS_HAVE_GC` flag bit is set.  More information
+   about Python's garbage collection scheme can be found in section
+   :ref:`supporting-cycle-detection`.
+
+   The :attr:`tp_traverse` pointer is used by the garbage collector to detect
+   reference cycles. A typical implementation of a :attr:`tp_traverse` function
+   simply calls :cfunc:`Py_VISIT` on each of the instance's members that are Python
+   objects.  For exampe, this is function :cfunc:`local_traverse` from the
+   :mod:`thread` extension module::
+
+      static int
+      local_traverse(localobject *self, visitproc visit, void *arg)
+      {
+          Py_VISIT(self->args);
+          Py_VISIT(self->kw);
+          Py_VISIT(self->dict);
+          return 0;
+      }
+
+   Note that :cfunc:`Py_VISIT` is called only on those members that can participate
+   in reference cycles.  Although there is also a ``self->key`` member, it can only
+   be *NULL* or a Python string and therefore cannot be part of a reference cycle.
+
+   On the other hand, even if you know a member can never be part of a cycle, as a
+   debugging aid you may want to visit it anyway just so the :mod:`gc` module's
+   :func:`get_referents` function will include it.
+
+   Note that :cfunc:`Py_VISIT` requires the *visit* and *arg* parameters to
+   :cfunc:`local_traverse` to have these specific names; don't name them just
+   anything.
+
+   This field is inherited by subtypes together with :attr:`tp_clear` and the
+   :const:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :attr:`tp_traverse`, and
+   :attr:`tp_clear` are all inherited from the base type if they are all zero in
+   the subtype *and* the subtype has the :const:`Py_TPFLAGS_HAVE_RICHCOMPARE` flag
+   bit set.
+
+
+.. cmember:: inquiry PyTypeObject.tp_clear
+
+   An optional pointer to a clear function for the garbage collector. This is only
+   used if the :const:`Py_TPFLAGS_HAVE_GC` flag bit is set.
+
+   The :attr:`tp_clear` member function is used to break reference cycles in cyclic
+   garbage detected by the garbage collector.  Taken together, all :attr:`tp_clear`
+   functions in the system must combine to break all reference cycles.  This is
+   subtle, and if in any doubt supply a :attr:`tp_clear` function.  For example,
+   the tuple type does not implement a :attr:`tp_clear` function, because it's
+   possible to prove that no reference cycle can be composed entirely of tuples.
+   Therefore the :attr:`tp_clear` functions of other types must be sufficient to
+   break any cycle containing a tuple.  This isn't immediately obvious, and there's
+   rarely a good reason to avoid implementing :attr:`tp_clear`.
+
+   Implementations of :attr:`tp_clear` should drop the instance's references to
+   those of its members that may be Python objects, and set its pointers to those
+   members to *NULL*, as in the following example::
+
+      static int
+      local_clear(localobject *self)
+      {
+          Py_CLEAR(self->key);
+          Py_CLEAR(self->args);
+          Py_CLEAR(self->kw);
+          Py_CLEAR(self->dict);
+          return 0;
+      }
+
+   The :cfunc:`Py_CLEAR` macro should be used, because clearing references is
+   delicate:  the reference to the contained object must not be decremented until
+   after the pointer to the contained object is set to *NULL*.  This is because
+   decrementing the reference count may cause the contained object to become trash,
+   triggering a chain of reclamation activity that may include invoking arbitrary
+   Python code (due to finalizers, or weakref callbacks, associated with the
+   contained object). If it's possible for such code to reference *self* again,
+   it's important that the pointer to the contained object be *NULL* at that time,
+   so that *self* knows the contained object can no longer be used.  The
+   :cfunc:`Py_CLEAR` macro performs the operations in a safe order.
+
+   Because the goal of :attr:`tp_clear` functions is to break reference cycles,
+   it's not necessary to clear contained objects like Python strings or Python
+   integers, which can't participate in reference cycles. On the other hand, it may
+   be convenient to clear all contained Python objects, and write the type's
+   :attr:`tp_dealloc` function to invoke :attr:`tp_clear`.
+
+   More information about Python's garbage collection scheme can be found in
+   section :ref:`supporting-cycle-detection`.
+
+   This field is inherited by subtypes together with :attr:`tp_traverse` and the
+   :const:`Py_TPFLAGS_HAVE_GC` flag bit: the flag bit, :attr:`tp_traverse`, and
+   :attr:`tp_clear` are all inherited from the base type if they are all zero in
+   the subtype *and* the subtype has the :const:`Py_TPFLAGS_HAVE_RICHCOMPARE` flag
+   bit set.
+
+
+.. cmember:: richcmpfunc PyTypeObject.tp_richcompare
+
+   An optional pointer to the rich comparison function.
+
+   The signature is the same as for :cfunc:`PyObject_RichCompare`. The function
+   should return the result of the comparison (usually ``Py_True`` or
+   ``Py_False``).  If the comparison is undefined, it must return
+   ``Py_NotImplemented``, if another error occurred it must return ``NULL`` and set
+   an exception condition.
+
+   This field is inherited by subtypes together with :attr:`tp_compare` and
+   :attr:`tp_hash`: a subtype inherits all three of :attr:`tp_compare`,
+   :attr:`tp_richcompare`, and :attr:`tp_hash`, when the subtype's
+   :attr:`tp_compare`, :attr:`tp_richcompare`, and :attr:`tp_hash` are all *NULL*.
+
+   The following constants are defined to be used as the third argument for
+   :attr:`tp_richcompare` and for :cfunc:`PyObject_RichCompare`:
+
+   +----------------+------------+
+   | Constant       | Comparison |
+   +================+============+
+   | :const:`Py_LT` | ``<``      |
+   +----------------+------------+
+   | :const:`Py_LE` | ``<=``     |
+   +----------------+------------+
+   | :const:`Py_EQ` | ``==``     |
+   +----------------+------------+
+   | :const:`Py_NE` | ``!=``     |
+   +----------------+------------+
+   | :const:`Py_GT` | ``>``      |
+   +----------------+------------+
+   | :const:`Py_GE` | ``>=``     |
+   +----------------+------------+
+
+The next field only exists if the :const:`Py_TPFLAGS_HAVE_WEAKREFS` flag bit is
+set.
+
+
+.. cmember:: long PyTypeObject.tp_weaklistoffset
+
+   If the instances of this type are weakly referenceable, this field is greater
+   than zero and contains the offset in the instance structure of the weak
+   reference list head (ignoring the GC header, if present); this offset is used by
+   :cfunc:`PyObject_ClearWeakRefs` and the :cfunc:`PyWeakref_\*` functions.  The
+   instance structure needs to include a field of type :ctype:`PyObject\*` which is
+   initialized to *NULL*.
+
+   Do not confuse this field with :attr:`tp_weaklist`; that is the list head for
+   weak references to the type object itself.
+
+   This field is inherited by subtypes, but see the rules listed below. A subtype
+   may override this offset; this means that the subtype uses a different weak
+   reference list head than the base type.  Since the list head is always found via
+   :attr:`tp_weaklistoffset`, this should not be a problem.
+
+   When a type defined by a class statement has no :attr:`__slots__` declaration,
+   and none of its base types are weakly referenceable, the type is made weakly
+   referenceable by adding a weak reference list head slot to the instance layout
+   and setting the :attr:`tp_weaklistoffset` of that slot's offset.
+
+   When a type's :attr:`__slots__` declaration contains a slot named
+   :attr:`__weakref__`, that slot becomes the weak reference list head for
+   instances of the type, and the slot's offset is stored in the type's
+   :attr:`tp_weaklistoffset`.
+
+   When a type's :attr:`__slots__` declaration does not contain a slot named
+   :attr:`__weakref__`, the type inherits its :attr:`tp_weaklistoffset` from its
+   base type.
+
+The next two fields only exist if the :const:`Py_TPFLAGS_HAVE_CLASS` flag bit is
+set.
+
+
+.. cmember:: getiterfunc PyTypeObject.tp_iter
+
+   An optional pointer to a function that returns an iterator for the object.  Its
+   presence normally signals that the instances of this type are iterable (although
+   sequences may be iterable without this function, and classic instances always
+   have this function, even if they don't define an :meth:`__iter__` method).
+
+   This function has the same signature as :cfunc:`PyObject_GetIter`.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: iternextfunc PyTypeObject.tp_iternext
+
+   An optional pointer to a function that returns the next item in an iterator, or
+   raises :exc:`StopIteration` when the iterator is exhausted.  Its presence
+   normally signals that the instances of this type are iterators (although classic
+   instances always have this function, even if they don't define a
+   :meth:`__next__` method).
+
+   Iterator types should also define the :attr:`tp_iter` function, and that
+   function should return the iterator instance itself (not a new iterator
+   instance).
+
+   This function has the same signature as :cfunc:`PyIter_Next`.
+
+   This field is inherited by subtypes.
+
+The next fields, up to and including :attr:`tp_weaklist`, only exist if the
+:const:`Py_TPFLAGS_HAVE_CLASS` flag bit is set.
+
+
+.. cmember:: struct PyMethodDef* PyTypeObject.tp_methods
+
+   An optional pointer to a static *NULL*-terminated array of :ctype:`PyMethodDef`
+   structures, declaring regular methods of this type.
+
+   For each entry in the array, an entry is added to the type's dictionary (see
+   :attr:`tp_dict` below) containing a method descriptor.
+
+   This field is not inherited by subtypes (methods are inherited through a
+   different mechanism).
+
+
+.. cmember:: struct PyMemberDef* PyTypeObject.tp_members
+
+   An optional pointer to a static *NULL*-terminated array of :ctype:`PyMemberDef`
+   structures, declaring regular data members (fields or slots) of instances of
+   this type.
+
+   For each entry in the array, an entry is added to the type's dictionary (see
+   :attr:`tp_dict` below) containing a member descriptor.
+
+   This field is not inherited by subtypes (members are inherited through a
+   different mechanism).
+
+
+.. cmember:: struct PyGetSetDef* PyTypeObject.tp_getset
+
+   An optional pointer to a static *NULL*-terminated array of :ctype:`PyGetSetDef`
+   structures, declaring computed attributes of instances of this type.
+
+   For each entry in the array, an entry is added to the type's dictionary (see
+   :attr:`tp_dict` below) containing a getset descriptor.
+
+   This field is not inherited by subtypes (computed attributes are inherited
+   through a different mechanism).
+
+   Docs for PyGetSetDef (XXX belong elsewhere)::
+
+      typedef PyObject *(*getter)(PyObject *, void *);
+      typedef int (*setter)(PyObject *, PyObject *, void *);
+
+      typedef struct PyGetSetDef {
+          char *name;    /* attribute name */
+          getter get;    /* C function to get the attribute */
+          setter set;    /* C function to set the attribute */
+          char *doc;     /* optional doc string */
+          void *closure; /* optional additional data for getter and setter */
+      } PyGetSetDef;
+
+
+.. cmember:: PyTypeObject* PyTypeObject.tp_base
+
+   An optional pointer to a base type from which type properties are inherited.  At
+   this level, only single inheritance is supported; multiple inheritance require
+   dynamically creating a type object by calling the metatype.
+
+   This field is not inherited by subtypes (obviously), but it defaults to
+   ``&PyBaseObject_Type`` (which to Python programmers is known as the type
+   :class:`object`).
+
+
+.. cmember:: PyObject* PyTypeObject.tp_dict
+
+   The type's dictionary is stored here by :cfunc:`PyType_Ready`.
+
+   This field should normally be initialized to *NULL* before PyType_Ready is
+   called; it may also be initialized to a dictionary containing initial attributes
+   for the type.  Once :cfunc:`PyType_Ready` has initialized the type, extra
+   attributes for the type may be added to this dictionary only if they don't
+   correspond to overloaded operations (like :meth:`__add__`).
+
+   This field is not inherited by subtypes (though the attributes defined in here
+   are inherited through a different mechanism).
+
+
+.. cmember:: descrgetfunc PyTypeObject.tp_descr_get
+
+   An optional pointer to a "descriptor get" function.
+
+   The function signature is ::
+
+      PyObject * tp_descr_get(PyObject *self, PyObject *obj, PyObject *type);
+
+   XXX blah, blah.
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: descrsetfunc PyTypeObject.tp_descr_set
+
+   An optional pointer to a "descriptor set" function.
+
+   The function signature is ::
+
+      int tp_descr_set(PyObject *self, PyObject *obj, PyObject *value);
+
+   This field is inherited by subtypes.
+
+   XXX blah, blah.
+
+
+.. cmember:: long PyTypeObject.tp_dictoffset
+
+   If the instances of this type have a dictionary containing instance variables,
+   this field is non-zero and contains the offset in the instances of the type of
+   the instance variable dictionary; this offset is used by
+   :cfunc:`PyObject_GenericGetAttr`.
+
+   Do not confuse this field with :attr:`tp_dict`; that is the dictionary for
+   attributes of the type object itself.
+
+   If the value of this field is greater than zero, it specifies the offset from
+   the start of the instance structure.  If the value is less than zero, it
+   specifies the offset from the *end* of the instance structure.  A negative
+   offset is more expensive to use, and should only be used when the instance
+   structure contains a variable-length part.  This is used for example to add an
+   instance variable dictionary to subtypes of :class:`str` or :class:`tuple`. Note
+   that the :attr:`tp_basicsize` field should account for the dictionary added to
+   the end in that case, even though the dictionary is not included in the basic
+   object layout.  On a system with a pointer size of 4 bytes,
+   :attr:`tp_dictoffset` should be set to ``-4`` to indicate that the dictionary is
+   at the very end of the structure.
+
+   The real dictionary offset in an instance can be computed from a negative
+   :attr:`tp_dictoffset` as follows::
+
+      dictoffset = tp_basicsize + abs(ob_size)*tp_itemsize + tp_dictoffset
+      if dictoffset is not aligned on sizeof(void*):
+          round up to sizeof(void*)
+
+   where :attr:`tp_basicsize`, :attr:`tp_itemsize` and :attr:`tp_dictoffset` are
+   taken from the type object, and :attr:`ob_size` is taken from the instance.  The
+   absolute value is taken because long ints use the sign of :attr:`ob_size` to
+   store the sign of the number.  (There's never a need to do this calculation
+   yourself; it is done for you by :cfunc:`_PyObject_GetDictPtr`.)
+
+   This field is inherited by subtypes, but see the rules listed below. A subtype
+   may override this offset; this means that the subtype instances store the
+   dictionary at a difference offset than the base type.  Since the dictionary is
+   always found via :attr:`tp_dictoffset`, this should not be a problem.
+
+   When a type defined by a class statement has no :attr:`__slots__` declaration,
+   and none of its base types has an instance variable dictionary, a dictionary
+   slot is added to the instance layout and the :attr:`tp_dictoffset` is set to
+   that slot's offset.
+
+   When a type defined by a class statement has a :attr:`__slots__` declaration,
+   the type inherits its :attr:`tp_dictoffset` from its base type.
+
+   (Adding a slot named :attr:`__dict__` to the :attr:`__slots__` declaration does
+   not have the expected effect, it just causes confusion.  Maybe this should be
+   added as a feature just like :attr:`__weakref__` though.)
+
+
+.. cmember:: initproc PyTypeObject.tp_init
+
+   An optional pointer to an instance initialization function.
+
+   This function corresponds to the :meth:`__init__` method of classes.  Like
+   :meth:`__init__`, it is possible to create an instance without calling
+   :meth:`__init__`, and it is possible to reinitialize an instance by calling its
+   :meth:`__init__` method again.
+
+   The function signature is ::
+
+      int tp_init(PyObject *self, PyObject *args, PyObject *kwds)
+
+   The self argument is the instance to be initialized; the *args* and *kwds*
+   arguments represent positional and keyword arguments of the call to
+   :meth:`__init__`.
+
+   The :attr:`tp_init` function, if not *NULL*, is called when an instance is
+   created normally by calling its type, after the type's :attr:`tp_new` function
+   has returned an instance of the type.  If the :attr:`tp_new` function returns an
+   instance of some other type that is not a subtype of the original type, no
+   :attr:`tp_init` function is called; if :attr:`tp_new` returns an instance of a
+   subtype of the original type, the subtype's :attr:`tp_init` is called.  (VERSION
+   NOTE: described here is what is implemented in Python 2.2.1 and later.  In
+   Python 2.2, the :attr:`tp_init` of the type of the object returned by
+   :attr:`tp_new` was always called, if not *NULL*.)
+
+   This field is inherited by subtypes.
+
+
+.. cmember:: allocfunc PyTypeObject.tp_alloc
+
+   An optional pointer to an instance allocation function.
+
+   The function signature is ::
+
+      PyObject *tp_alloc(PyTypeObject *self, Py_ssize_t nitems)
+
+   The purpose of this function is to separate memory allocation from memory
+   initialization.  It should return a pointer to a block of memory of adequate
+   length for the instance, suitably aligned, and initialized to zeros, but with
+   :attr:`ob_refcnt` set to ``1`` and :attr:`ob_type` set to the type argument.  If
+   the type's :attr:`tp_itemsize` is non-zero, the object's :attr:`ob_size` field
+   should be initialized to *nitems* and the length of the allocated memory block
+   should be ``tp_basicsize + nitems*tp_itemsize``, rounded up to a multiple of
+   ``sizeof(void*)``; otherwise, *nitems* is not used and the length of the block
+   should be :attr:`tp_basicsize`.
+
+   Do not use this function to do any other instance initialization, not even to
+   allocate additional memory; that should be done by :attr:`tp_new`.
+
+   This field is inherited by static subtypes, but not by dynamic subtypes
+   (subtypes created by a class statement); in the latter, this field is always set
+   to :cfunc:`PyType_GenericAlloc`, to force a standard heap allocation strategy.
+   That is also the recommended value for statically defined types.
+
+
+.. cmember:: newfunc PyTypeObject.tp_new
+
+   An optional pointer to an instance creation function.
+
+   If this function is *NULL* for a particular type, that type cannot be called to
+   create new instances; presumably there is some other way to create instances,
+   like a factory function.
+
+   The function signature is ::
+
+      PyObject *tp_new(PyTypeObject *subtype, PyObject *args, PyObject *kwds)
+
+   The subtype argument is the type of the object being created; the *args* and
+   *kwds* arguments represent positional and keyword arguments of the call to the
+   type.  Note that subtype doesn't have to equal the type whose :attr:`tp_new`
+   function is called; it may be a subtype of that type (but not an unrelated
+   type).
+
+   The :attr:`tp_new` function should call ``subtype->tp_alloc(subtype, nitems)``
+   to allocate space for the object, and then do only as much further
+   initialization as is absolutely necessary.  Initialization that can safely be
+   ignored or repeated should be placed in the :attr:`tp_init` handler.  A good
+   rule of thumb is that for immutable types, all initialization should take place
+   in :attr:`tp_new`, while for mutable types, most initialization should be
+   deferred to :attr:`tp_init`.
+
+   This field is inherited by subtypes, except it is not inherited by static types
+   whose :attr:`tp_base` is *NULL* or ``&PyBaseObject_Type``.  The latter exception
+   is a precaution so that old extension types don't become callable simply by
+   being linked with Python 2.2.
+
+
+.. cmember:: destructor PyTypeObject.tp_free
+
+   An optional pointer to an instance deallocation function.
+
+   The signature of this function has changed slightly: in Python 2.2 and 2.2.1,
+   its signature is :ctype:`destructor`::
+
+      void tp_free(PyObject *)
+
+   In Python 2.3 and beyond, its signature is :ctype:`freefunc`::
+
+      void tp_free(void *)
+
+   The only initializer that is compatible with both versions is ``_PyObject_Del``,
+   whose definition has suitably adapted in Python 2.3.
+
+   This field is inherited by static subtypes, but not by dynamic subtypes
+   (subtypes created by a class statement); in the latter, this field is set to a
+   deallocator suitable to match :cfunc:`PyType_GenericAlloc` and the value of the
+   :const:`Py_TPFLAGS_HAVE_GC` flag bit.
+
+
+.. cmember:: inquiry PyTypeObject.tp_is_gc
+
+   An optional pointer to a function called by the garbage collector.
+
+   The garbage collector needs to know whether a particular object is collectible
+   or not.  Normally, it is sufficient to look at the object's type's
+   :attr:`tp_flags` field, and check the :const:`Py_TPFLAGS_HAVE_GC` flag bit.  But
+   some types have a mixture of statically and dynamically allocated instances, and
+   the statically allocated instances are not collectible.  Such types should
+   define this function; it should return ``1`` for a collectible instance, and
+   ``0`` for a non-collectible instance. The signature is ::
+
+      int tp_is_gc(PyObject *self)
+
+   (The only example of this are types themselves.  The metatype,
+   :cdata:`PyType_Type`, defines this function to distinguish between statically
+   and dynamically allocated types.)
+
+   This field is inherited by subtypes.  (VERSION NOTE: in Python 2.2, it was not
+   inherited.  It is inherited in 2.2.1 and later versions.)
+
+
+.. cmember:: PyObject* PyTypeObject.tp_bases
+
+   Tuple of base types.
+
+   This is set for types created by a class statement.  It should be *NULL* for
+   statically defined types.
+
+   This field is not inherited.
+
+
+.. cmember:: PyObject* PyTypeObject.tp_mro
+
+   Tuple containing the expanded set of base types, starting with the type itself
+   and ending with :class:`object`, in Method Resolution Order.
+
+   This field is not inherited; it is calculated fresh by :cfunc:`PyType_Ready`.
+
+
+.. cmember:: PyObject* PyTypeObject.tp_cache
+
+   Unused.  Not inherited.  Internal use only.
+
+
+.. cmember:: PyObject* PyTypeObject.tp_subclasses
+
+   List of weak references to subclasses.  Not inherited.  Internal use only.
+
+
+.. cmember:: PyObject* PyTypeObject.tp_weaklist
+
+   Weak reference list head, for weak references to this type object.  Not
+   inherited.  Internal use only.
+
+The remaining fields are only defined if the feature test macro
+:const:`COUNT_ALLOCS` is defined, and are for internal use only. They are
+documented here for completeness.  None of these fields are inherited by
+subtypes.
+
+
+.. cmember:: Py_ssize_t PyTypeObject.tp_allocs
+
+   Number of allocations.
+
+
+.. cmember:: Py_ssize_t PyTypeObject.tp_frees
+
+   Number of frees.
+
+
+.. cmember:: Py_ssize_t PyTypeObject.tp_maxalloc
+
+   Maximum simultaneously allocated objects.
+
+
+.. cmember:: PyTypeObject* PyTypeObject.tp_next
+
+   Pointer to the next type object with a non-zero :attr:`tp_allocs` field.
+
+Also, note that, in a garbage collected Python, tp_dealloc may be called from
+any Python thread, not just the thread which created the object (if the object
+becomes part of a refcount cycle, that cycle might be collected by a garbage
+collection on any thread).  This is not a problem for Python API calls, since
+the thread on which tp_dealloc is called will own the Global Interpreter Lock
+(GIL). However, if the object being destroyed in turn destroys objects from some
+other C or C++ library, care should be taken to ensure that destroying those
+objects on the thread which called tp_dealloc will not violate any assumptions
+of the library.
+
+
+.. _mapping-structs:
+
+Mapping Object Structures
+=========================
+
+
+.. ctype:: PyMappingMethods
+
+   Structure used to hold pointers to the functions used to implement the mapping
+   protocol for an extension type.
+
+
+.. _number-structs:
+
+Number Object Structures
+========================
+
+
+.. ctype:: PyNumberMethods
+
+   Structure used to hold pointers to the functions an extension type uses to
+   implement the number protocol.
+
+
+.. _sequence-structs:
+
+Sequence Object Structures
+==========================
+
+
+.. ctype:: PySequenceMethods
+
+   Structure used to hold pointers to the functions which an object uses to
+   implement the sequence protocol.
+
+
+.. _buffer-structs:
+
+Buffer Object Structures
+========================
+
+.. sectionauthor:: Greg J. Stein <greg@lyra.org>
+
+
+The buffer interface exports a model where an object can expose its internal
+data as a set of chunks of data, where each chunk is specified as a
+pointer/length pair.  These chunks are called :dfn:`segments` and are presumed
+to be non-contiguous in memory.
+
+If an object does not export the buffer interface, then its :attr:`tp_as_buffer`
+member in the :ctype:`PyTypeObject` structure should be *NULL*.  Otherwise, the
+:attr:`tp_as_buffer` will point to a :ctype:`PyBufferProcs` structure.
+
+.. note::
+
+   It is very important that your :ctype:`PyTypeObject` structure uses
+   :const:`Py_TPFLAGS_DEFAULT` for the value of the :attr:`tp_flags` member rather
+   than ``0``.  This tells the Python runtime that your :ctype:`PyBufferProcs`
+   structure contains the :attr:`bf_getcharbuffer` slot. Older versions of Python
+   did not have this member, so a new Python interpreter using an old extension
+   needs to be able to test for its presence before using it.
+
+
+.. ctype:: PyBufferProcs
+
+   Structure used to hold the function pointers which define an implementation of
+   the buffer protocol.
+
+   The first slot is :attr:`bf_getreadbuffer`, of type :ctype:`getreadbufferproc`.
+   If this slot is *NULL*, then the object does not support reading from the
+   internal data.  This is non-sensical, so implementors should fill this in, but
+   callers should test that the slot contains a non-*NULL* value.
+
+   The next slot is :attr:`bf_getwritebuffer` having type
+   :ctype:`getwritebufferproc`.  This slot may be *NULL* if the object does not
+   allow writing into its returned buffers.
+
+   The third slot is :attr:`bf_getsegcount`, with type :ctype:`getsegcountproc`.
+   This slot must not be *NULL* and is used to inform the caller how many segments
+   the object contains.  Simple objects such as :ctype:`PyString_Type` and
+   :ctype:`PyBuffer_Type` objects contain a single segment.
+
+   .. index:: single: PyType_HasFeature()
+
+   The last slot is :attr:`bf_getcharbuffer`, of type :ctype:`getcharbufferproc`.
+   This slot will only be present if the :const:`Py_TPFLAGS_HAVE_GETCHARBUFFER`
+   flag is present in the :attr:`tp_flags` field of the object's
+   :ctype:`PyTypeObject`. Before using this slot, the caller should test whether it
+   is present by using the :cfunc:`PyType_HasFeature` function.  If the flag is
+   present, :attr:`bf_getcharbuffer` may be *NULL*, indicating that the object's
+   contents cannot be used as *8-bit characters*. The slot function may also raise
+   an error if the object's contents cannot be interpreted as 8-bit characters.
+   For example, if the object is an array which is configured to hold floating
+   point values, an exception may be raised if a caller attempts to use
+   :attr:`bf_getcharbuffer` to fetch a sequence of 8-bit characters. This notion of
+   exporting the internal buffers as "text" is used to distinguish between objects
+   that are binary in nature, and those which have character-based content.
+
+   .. note::
+
+      The current policy seems to state that these characters may be multi-byte
+      characters. This implies that a buffer size of *N* does not mean there are *N*
+      characters present.
+
+
+.. data:: Py_TPFLAGS_HAVE_GETCHARBUFFER
+
+   Flag bit set in the type structure to indicate that the :attr:`bf_getcharbuffer`
+   slot is known.  This being set does not indicate that the object supports the
+   buffer interface or that the :attr:`bf_getcharbuffer` slot is non-*NULL*.
+
+
+.. ctype:: Py_ssize_t (*readbufferproc) (PyObject *self, Py_ssize_t segment, void **ptrptr)
+
+   Return a pointer to a readable segment of the buffer in ``*ptrptr``.  This
+   function is allowed to raise an exception, in which case it must return ``-1``.
+   The *segment* which is specified must be zero or positive, and strictly less
+   than the number of segments returned by the :attr:`bf_getsegcount` slot
+   function.  On success, it returns the length of the segment, and sets
+   ``*ptrptr`` to a pointer to that memory.
+
+
+.. ctype:: Py_ssize_t (*writebufferproc) (PyObject *self, Py_ssize_t segment, void **ptrptr)
+
+   Return a pointer to a writable memory buffer in ``*ptrptr``, and the length of
+   that segment as the function return value.  The memory buffer must correspond to
+   buffer segment *segment*.  Must return ``-1`` and set an exception on error.
+   :exc:`TypeError` should be raised if the object only supports read-only buffers,
+   and :exc:`SystemError` should be raised when *segment* specifies a segment that
+   doesn't exist.
+
+   .. % Why doesn't it raise ValueError for this one?
+   .. % GJS: because you shouldn't be calling it with an invalid
+   .. % segment. That indicates a blatant programming error in the C
+   .. % code.
+
+
+.. ctype:: Py_ssize_t (*segcountproc) (PyObject *self, Py_ssize_t *lenp)
+
+   Return the number of memory segments which comprise the buffer.  If *lenp* is
+   not *NULL*, the implementation must report the sum of the sizes (in bytes) of
+   all segments in ``*lenp``. The function cannot fail.
+
+
+.. ctype:: Py_ssize_t (*charbufferproc) (PyObject *self, Py_ssize_t segment, const char **ptrptr)
+
+   Return the size of the segment *segment* that *ptrptr*  is set to.  ``*ptrptr``
+   is set to the memory buffer. Returns ``-1`` on error.
+
+
+.. _supporting-iteration:
+
+Supporting the Iterator Protocol
+================================
+
+
+.. _supporting-cycle-detection:
+
+Supporting Cyclic Garbage Collection
+====================================
+
+Python's support for detecting and collecting garbage which involves circular
+references requires support from object types which are "containers" for other
+objects which may also be containers.  Types which do not store references to
+other objects, or which only store references to atomic types (such as numbers
+or strings), do not need to provide any explicit support for garbage collection.
+
+.. An example showing the use of these interfaces can be found in "Supporting the
+.. Cycle Collector (XXX not found: ../ext/example-cycle-support.html)".
+
+To create a container type, the :attr:`tp_flags` field of the type object must
+include the :const:`Py_TPFLAGS_HAVE_GC` and provide an implementation of the
+:attr:`tp_traverse` handler.  If instances of the type are mutable, a
+:attr:`tp_clear` implementation must also be provided.
+
+
+.. data:: Py_TPFLAGS_HAVE_GC
+
+   Objects with a type with this flag set must conform with the rules documented
+   here.  For convenience these objects will be referred to as container objects.
+
+Constructors for container types must conform to two rules:
+
+#. The memory for the object must be allocated using :cfunc:`PyObject_GC_New` or
+   :cfunc:`PyObject_GC_VarNew`.
+
+#. Once all the fields which may contain references to other containers are
+   initialized, it must call :cfunc:`PyObject_GC_Track`.
+
+
+.. cfunction:: TYPE* PyObject_GC_New(TYPE, PyTypeObject *type)
+
+   Analogous to :cfunc:`PyObject_New` but for container objects with the
+   :const:`Py_TPFLAGS_HAVE_GC` flag set.
+
+
+.. cfunction:: TYPE* PyObject_GC_NewVar(TYPE, PyTypeObject *type, Py_ssize_t size)
+
+   Analogous to :cfunc:`PyObject_NewVar` but for container objects with the
+   :const:`Py_TPFLAGS_HAVE_GC` flag set.
+
+
+.. cfunction:: PyVarObject * PyObject_GC_Resize(PyVarObject *op, Py_ssize_t)
+
+   Resize an object allocated by :cfunc:`PyObject_NewVar`.  Returns the resized
+   object or *NULL* on failure.
+
+
+.. cfunction:: void PyObject_GC_Track(PyObject *op)
+
+   Adds the object *op* to the set of container objects tracked by the collector.
+   The collector can run at unexpected times so objects must be valid while being
+   tracked.  This should be called once all the fields followed by the
+   :attr:`tp_traverse` handler become valid, usually near the end of the
+   constructor.
+
+
+.. cfunction:: void _PyObject_GC_TRACK(PyObject *op)
+
+   A macro version of :cfunc:`PyObject_GC_Track`.  It should not be used for
+   extension modules.
+
+Similarly, the deallocator for the object must conform to a similar pair of
+rules:
+
+#. Before fields which refer to other containers are invalidated,
+   :cfunc:`PyObject_GC_UnTrack` must be called.
+
+#. The object's memory must be deallocated using :cfunc:`PyObject_GC_Del`.
+
+
+.. cfunction:: void PyObject_GC_Del(void *op)
+
+   Releases memory allocated to an object using :cfunc:`PyObject_GC_New` or
+   :cfunc:`PyObject_GC_NewVar`.
+
+
+.. cfunction:: void PyObject_GC_UnTrack(void *op)
+
+   Remove the object *op* from the set of container objects tracked by the
+   collector.  Note that :cfunc:`PyObject_GC_Track` can be called again on this
+   object to add it back to the set of tracked objects.  The deallocator
+   (:attr:`tp_dealloc` handler) should call this for the object before any of the
+   fields used by the :attr:`tp_traverse` handler become invalid.
+
+
+.. cfunction:: void _PyObject_GC_UNTRACK(PyObject *op)
+
+   A macro version of :cfunc:`PyObject_GC_UnTrack`.  It should not be used for
+   extension modules.
+
+The :attr:`tp_traverse` handler accepts a function parameter of this type:
+
+
+.. ctype:: int (*visitproc)(PyObject *object, void *arg)
+
+   Type of the visitor function passed to the :attr:`tp_traverse` handler.  The
+   function should be called with an object to traverse as *object* and the third
+   parameter to the :attr:`tp_traverse` handler as *arg*.  The Python core uses
+   several visitor functions to implement cyclic garbage detection; it's not
+   expected that users will need to write their own visitor functions.
+
+The :attr:`tp_traverse` handler must have the following type:
+
+
+.. ctype:: int (*traverseproc)(PyObject *self, visitproc visit, void *arg)
+
+   Traversal function for a container object.  Implementations must call the
+   *visit* function for each object directly contained by *self*, with the
+   parameters to *visit* being the contained object and the *arg* value passed to
+   the handler.  The *visit* function must not be called with a *NULL* object
+   argument.  If *visit* returns a non-zero value that value should be returned
+   immediately.
+
+To simplify writing :attr:`tp_traverse` handlers, a :cfunc:`Py_VISIT` macro is
+provided.  In order to use this macro, the :attr:`tp_traverse` implementation
+must name its arguments exactly *visit* and *arg*:
+
+
+.. cfunction:: void Py_VISIT(PyObject *o)
+
+   Call the *visit* callback, with arguments *o* and *arg*. If *visit* returns a
+   non-zero value, then return it.  Using this macro, :attr:`tp_traverse` handlers
+   look like::
+
+      static int
+      my_traverse(Noddy *self, visitproc visit, void *arg)
+      {
+          Py_VISIT(self->foo);
+          Py_VISIT(self->bar);
+          return 0;
+      }
+
+   .. versionadded:: 2.4
+
+The :attr:`tp_clear` handler must be of the :ctype:`inquiry` type, or *NULL* if
+the object is immutable.
+
+
+.. ctype:: int (*inquiry)(PyObject *self)
+
+   Drop references that may have created reference cycles.  Immutable objects do
+   not have to define this method since they can never directly create reference
+   cycles.  Note that the object must still be valid after calling this method
+   (don't just call :cfunc:`Py_DECREF` on a reference).  The collector will call
+   this method if it detects that this object is involved in a reference cycle.
+
diff --git a/Doc/c-api/refcounting.rst b/Doc/c-api/refcounting.rst
new file mode 100644
index 0000000..9dc357f
--- /dev/null
+++ b/Doc/c-api/refcounting.rst
@@ -0,0 +1,74 @@
+.. highlightlang:: c
+
+
+.. _countingrefs:
+
+******************
+Reference Counting
+******************
+
+The macros in this section are used for managing reference counts of Python
+objects.
+
+
+.. cfunction:: void Py_INCREF(PyObject *o)
+
+   Increment the reference count for object *o*.  The object must not be *NULL*; if
+   you aren't sure that it isn't *NULL*, use :cfunc:`Py_XINCREF`.
+
+
+.. cfunction:: void Py_XINCREF(PyObject *o)
+
+   Increment the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect.
+
+
+.. cfunction:: void Py_DECREF(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object must not be *NULL*; if
+   you aren't sure that it isn't *NULL*, use :cfunc:`Py_XDECREF`.  If the reference
+   count reaches zero, the object's type's deallocation function (which must not be
+   *NULL*) is invoked.
+
+   .. warning::
+
+      The deallocation function can cause arbitrary Python code to be invoked (e.g.
+      when a class instance with a :meth:`__del__` method is deallocated).  While
+      exceptions in such code are not propagated, the executed code has free access to
+      all Python global variables.  This means that any object that is reachable from
+      a global variable should be in a consistent state before :cfunc:`Py_DECREF` is
+      invoked.  For example, code to delete an object from a list should copy a
+      reference to the deleted object in a temporary variable, update the list data
+      structure, and then call :cfunc:`Py_DECREF` for the temporary variable.
+
+
+.. cfunction:: void Py_XDECREF(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect; otherwise the effect is the same as for
+   :cfunc:`Py_DECREF`, and the same warning applies.
+
+
+.. cfunction:: void Py_CLEAR(PyObject *o)
+
+   Decrement the reference count for object *o*.  The object may be *NULL*, in
+   which case the macro has no effect; otherwise the effect is the same as for
+   :cfunc:`Py_DECREF`, except that the argument is also set to *NULL*.  The warning
+   for :cfunc:`Py_DECREF` does not apply with respect to the object passed because
+   the macro carefully uses a temporary variable and sets the argument to *NULL*
+   before decrementing its reference count.
+
+   It is a good idea to use this macro whenever decrementing the value of a
+   variable that might be traversed during garbage collection.
+
+   .. versionadded:: 2.4
+
+The following functions are for runtime dynamic embedding of Python:
+``Py_IncRef(PyObject \*o)``, `Py_DecRef(PyObject \*o)``. They are
+simply exported function versions of :cfunc:`Py_XINCREF` and
+:cfunc:`Py_XDECREF`, respectively.
+
+The following functions or macros are only for use within the interpreter core:
+:cfunc:`_Py_Dealloc`, :cfunc:`_Py_ForgetReference`, :cfunc:`_Py_NewReference`,
+as well as the global variable :cdata:`_Py_RefTotal`.
+
diff --git a/Doc/c-api/utilities.rst b/Doc/c-api/utilities.rst
new file mode 100644
index 0000000..01c1ceb
--- /dev/null
+++ b/Doc/c-api/utilities.rst
@@ -0,0 +1,1030 @@
+.. highlightlang:: c
+
+
+.. _utilities:
+
+*********
+Utilities
+*********
+
+The functions in this chapter perform various utility tasks, ranging from
+helping C code be more portable across platforms, using Python modules from C,
+and parsing function arguments and constructing Python values from C values.
+
+
+.. _os:
+
+Operating System Utilities
+==========================
+
+
+.. cfunction:: int Py_FdIsInteractive(FILE *fp, const char *filename)
+
+   Return true (nonzero) if the standard I/O file *fp* with name *filename* is
+   deemed interactive.  This is the case for files for which ``isatty(fileno(fp))``
+   is true.  If the global flag :cdata:`Py_InteractiveFlag` is true, this function
+   also returns true if the *filename* pointer is *NULL* or if the name is equal to
+   one of the strings ``'<stdin>'`` or ``'???'``.
+
+
+.. cfunction:: long PyOS_GetLastModificationTime(char *filename)
+
+   Return the time of last modification of the file *filename*. The result is
+   encoded in the same way as the timestamp returned by the standard C library
+   function :cfunc:`time`.
+
+
+.. cfunction:: void PyOS_AfterFork()
+
+   Function to update some internal state after a process fork; this should be
+   called in the new process if the Python interpreter will continue to be used.
+   If a new executable is loaded into the new process, this function does not need
+   to be called.
+
+
+.. cfunction:: int PyOS_CheckStack()
+
+   Return true when the interpreter runs out of stack space.  This is a reliable
+   check, but is only available when :const:`USE_STACKCHECK` is defined (currently
+   on Windows using the Microsoft Visual C++ compiler).  :const:`USE_STACKCHECK`
+   will be defined automatically; you should never change the definition in your
+   own code.
+
+
+.. cfunction:: PyOS_sighandler_t PyOS_getsig(int i)
+
+   Return the current signal handler for signal *i*.  This is a thin wrapper around
+   either :cfunc:`sigaction` or :cfunc:`signal`.  Do not call those functions
+   directly! :ctype:`PyOS_sighandler_t` is a typedef alias for :ctype:`void
+   (\*)(int)`.
+
+
+.. cfunction:: PyOS_sighandler_t PyOS_setsig(int i, PyOS_sighandler_t h)
+
+   Set the signal handler for signal *i* to be *h*; return the old signal handler.
+   This is a thin wrapper around either :cfunc:`sigaction` or :cfunc:`signal`.  Do
+   not call those functions directly!  :ctype:`PyOS_sighandler_t` is a typedef
+   alias for :ctype:`void (\*)(int)`.
+
+
+.. _processcontrol:
+
+Process Control
+===============
+
+
+.. cfunction:: void Py_FatalError(const char *message)
+
+   .. index:: single: abort()
+
+   Print a fatal error message and kill the process.  No cleanup is performed.
+   This function should only be invoked when a condition is detected that would
+   make it dangerous to continue using the Python interpreter; e.g., when the
+   object administration appears to be corrupted.  On Unix, the standard C library
+   function :cfunc:`abort` is called which will attempt to produce a :file:`core`
+   file.
+
+
+.. cfunction:: void Py_Exit(int status)
+
+   .. index::
+      single: Py_Finalize()
+      single: exit()
+
+   Exit the current process.  This calls :cfunc:`Py_Finalize` and then calls the
+   standard C library function ``exit(status)``.
+
+
+.. cfunction:: int Py_AtExit(void (*func) ())
+
+   .. index::
+      single: Py_Finalize()
+      single: cleanup functions
+
+   Register a cleanup function to be called by :cfunc:`Py_Finalize`.  The cleanup
+   function will be called with no arguments and should return no value.  At most
+   32 cleanup functions can be registered.  When the registration is successful,
+   :cfunc:`Py_AtExit` returns ``0``; on failure, it returns ``-1``.  The cleanup
+   function registered last is called first. Each cleanup function will be called
+   at most once.  Since Python's internal finalization will have completed before
+   the cleanup function, no Python APIs should be called by *func*.
+
+
+.. _importing:
+
+Importing Modules
+=================
+
+
+.. cfunction:: PyObject* PyImport_ImportModule(const char *name)
+
+   .. index::
+      single: package variable; __all__
+      single: __all__ (package variable)
+
+   This is a simplified interface to :cfunc:`PyImport_ImportModuleEx` below,
+   leaving the *globals* and *locals* arguments set to *NULL*.  When the *name*
+   argument contains a dot (when it specifies a submodule of a package), the
+   *fromlist* argument is set to the list ``['*']`` so that the return value is the
+   named module rather than the top-level package containing it as would otherwise
+   be the case.  (Unfortunately, this has an additional side effect when *name* in
+   fact specifies a subpackage instead of a submodule: the submodules specified in
+   the package's ``__all__`` variable are  loaded.)  Return a new reference to the
+   imported module, or *NULL* with an exception set on failure.  Before Python 2.4,
+   the module may still be created in the failure case --- examine ``sys.modules``
+   to find out.  Starting with Python 2.4, a failing import of a module no longer
+   leaves the module in ``sys.modules``.
+
+   .. versionchanged:: 2.4
+      failing imports remove incomplete module objects.
+
+   .. index:: single: modules (in module sys)
+
+
+.. cfunction:: PyObject* PyImport_ImportModuleEx(char *name, PyObject *globals, PyObject *locals, PyObject *fromlist)
+
+   .. index:: builtin: __import__
+
+   Import a module.  This is best described by referring to the built-in Python
+   function :func:`__import__`, as the standard :func:`__import__` function calls
+   this function directly.
+
+   The return value is a new reference to the imported module or top-level package,
+   or *NULL* with an exception set on failure (before Python 2.4, the module may
+   still be created in this case).  Like for :func:`__import__`, the return value
+   when a submodule of a package was requested is normally the top-level package,
+   unless a non-empty *fromlist* was given.
+
+   .. versionchanged:: 2.4
+      failing imports remove incomplete module objects.
+
+
+.. cfunction:: PyObject* PyImport_Import(PyObject *name)
+
+   .. index::
+      module: rexec
+      module: ihooks
+
+   This is a higher-level interface that calls the current "import hook function".
+   It invokes the :func:`__import__` function from the ``__builtins__`` of the
+   current globals.  This means that the import is done using whatever import hooks
+   are installed in the current environment, e.g. by :mod:`rexec` or :mod:`ihooks`.
+
+
+.. cfunction:: PyObject* PyImport_ReloadModule(PyObject *m)
+
+   Reload a module.  Return a new reference to the reloaded module, or *NULL* with
+   an exception set on failure (the module still exists in this case).
+
+
+.. cfunction:: PyObject* PyImport_AddModule(const char *name)
+
+   Return the module object corresponding to a module name.  The *name* argument
+   may be of the form ``package.module``. First check the modules dictionary if
+   there's one there, and if not, create a new one and insert it in the modules
+   dictionary. Return *NULL* with an exception set on failure.
+
+   .. note::
+
+      This function does not load or import the module; if the module wasn't already
+      loaded, you will get an empty module object. Use :cfunc:`PyImport_ImportModule`
+      or one of its variants to import a module.  Package structures implied by a
+      dotted name for *name* are not created if not already present.
+
+
+.. cfunction:: PyObject* PyImport_ExecCodeModule(char *name, PyObject *co)
+
+   .. index:: builtin: compile
+
+   Given a module name (possibly of the form ``package.module``) and a code object
+   read from a Python bytecode file or obtained from the built-in function
+   :func:`compile`, load the module.  Return a new reference to the module object,
+   or *NULL* with an exception set if an error occurred.  Before Python 2.4, the
+   module could still be created in error cases.  Starting with Python 2.4, *name*
+   is removed from ``sys.modules`` in error cases, and even if *name* was already
+   in ``sys.modules`` on entry to :cfunc:`PyImport_ExecCodeModule`.  Leaving
+   incompletely initialized modules in ``sys.modules`` is dangerous, as imports of
+   such modules have no way to know that the module object is an unknown (and
+   probably damaged with respect to the module author's intents) state.
+
+   This function will reload the module if it was already imported.  See
+   :cfunc:`PyImport_ReloadModule` for the intended way to reload a module.
+
+   If *name* points to a dotted name of the form ``package.module``, any package
+   structures not already created will still not be created.
+
+   .. versionchanged:: 2.4
+      *name* is removed from ``sys.modules`` in error cases.
+
+
+.. cfunction:: long PyImport_GetMagicNumber()
+
+   Return the magic number for Python bytecode files (a.k.a. :file:`.pyc` and
+   :file:`.pyo` files).  The magic number should be present in the first four bytes
+   of the bytecode file, in little-endian byte order.
+
+
+.. cfunction:: PyObject* PyImport_GetModuleDict()
+
+   Return the dictionary used for the module administration (a.k.a.
+   ``sys.modules``).  Note that this is a per-interpreter variable.
+
+
+.. cfunction:: void _PyImport_Init()
+
+   Initialize the import mechanism.  For internal use only.
+
+
+.. cfunction:: void PyImport_Cleanup()
+
+   Empty the module table.  For internal use only.
+
+
+.. cfunction:: void _PyImport_Fini()
+
+   Finalize the import mechanism.  For internal use only.
+
+
+.. cfunction:: PyObject* _PyImport_FindExtension(char *, char *)
+
+   For internal use only.
+
+
+.. cfunction:: PyObject* _PyImport_FixupExtension(char *, char *)
+
+   For internal use only.
+
+
+.. cfunction:: int PyImport_ImportFrozenModule(char *name)
+
+   Load a frozen module named *name*.  Return ``1`` for success, ``0`` if the
+   module is not found, and ``-1`` with an exception set if the initialization
+   failed.  To access the imported module on a successful load, use
+   :cfunc:`PyImport_ImportModule`.  (Note the misnomer --- this function would
+   reload the module if it was already imported.)
+
+
+.. ctype:: struct _frozen
+
+   .. index:: single: freeze utility
+
+   This is the structure type definition for frozen module descriptors, as
+   generated by the :program:`freeze` utility (see :file:`Tools/freeze/` in the
+   Python source distribution).  Its definition, found in :file:`Include/import.h`,
+   is::
+
+      struct _frozen {
+          char *name;
+          unsigned char *code;
+          int size;
+      };
+
+
+.. cvar:: struct _frozen* PyImport_FrozenModules
+
+   This pointer is initialized to point to an array of :ctype:`struct _frozen`
+   records, terminated by one whose members are all *NULL* or zero.  When a frozen
+   module is imported, it is searched in this table.  Third-party code could play
+   tricks with this to provide a dynamically created collection of frozen modules.
+
+
+.. cfunction:: int PyImport_AppendInittab(char *name, void (*initfunc)(void))
+
+   Add a single module to the existing table of built-in modules.  This is a
+   convenience wrapper around :cfunc:`PyImport_ExtendInittab`, returning ``-1`` if
+   the table could not be extended.  The new module can be imported by the name
+   *name*, and uses the function *initfunc* as the initialization function called
+   on the first attempted import.  This should be called before
+   :cfunc:`Py_Initialize`.
+
+
+.. ctype:: struct _inittab
+
+   Structure describing a single entry in the list of built-in modules.  Each of
+   these structures gives the name and initialization function for a module built
+   into the interpreter.  Programs which embed Python may use an array of these
+   structures in conjunction with :cfunc:`PyImport_ExtendInittab` to provide
+   additional built-in modules.  The structure is defined in
+   :file:`Include/import.h` as::
+
+      struct _inittab {
+          char *name;
+          void (*initfunc)(void);
+      };
+
+
+.. cfunction:: int PyImport_ExtendInittab(struct _inittab *newtab)
+
+   Add a collection of modules to the table of built-in modules.  The *newtab*
+   array must end with a sentinel entry which contains *NULL* for the :attr:`name`
+   field; failure to provide the sentinel value can result in a memory fault.
+   Returns ``0`` on success or ``-1`` if insufficient memory could be allocated to
+   extend the internal table.  In the event of failure, no modules are added to the
+   internal table.  This should be called before :cfunc:`Py_Initialize`.
+
+
+.. _marshalling-utils:
+
+Data marshalling support
+========================
+
+These routines allow C code to work with serialized objects using the same data
+format as the :mod:`marshal` module.  There are functions to write data into the
+serialization format, and additional functions that can be used to read the data
+back.  Files used to store marshalled data must be opened in binary mode.
+
+Numeric values are stored with the least significant byte first.
+
+The module supports two versions of the data format: version 0 is the historical
+version, version 1 (new in Python 2.4) shares interned strings in the file, and
+upon unmarshalling. *Py_MARSHAL_VERSION* indicates the current file format
+(currently 1).
+
+
+.. cfunction:: void PyMarshal_WriteLongToFile(long value, FILE *file, int version)
+
+   Marshal a :ctype:`long` integer, *value*, to *file*.  This will only write the
+   least-significant 32 bits of *value*; regardless of the size of the native
+   :ctype:`long` type.
+
+   .. versionchanged:: 2.4
+      *version* indicates the file format.
+
+
+.. cfunction:: void PyMarshal_WriteObjectToFile(PyObject *value, FILE *file, int version)
+
+   Marshal a Python object, *value*, to *file*.
+
+   .. versionchanged:: 2.4
+      *version* indicates the file format.
+
+
+.. cfunction:: PyObject* PyMarshal_WriteObjectToString(PyObject *value, int version)
+
+   Return a string object containing the marshalled representation of *value*.
+
+   .. versionchanged:: 2.4
+      *version* indicates the file format.
+
+
+The following functions allow marshalled values to be read back in.
+
+XXX What about error detection?  It appears that reading past the end of the
+file will always result in a negative numeric value (where that's relevant), but
+it's not clear that negative values won't be handled properly when there's no
+error.  What's the right way to tell? Should only non-negative values be written
+using these routines?
+
+
+.. cfunction:: long PyMarshal_ReadLongFromFile(FILE *file)
+
+   Return a C :ctype:`long` from the data stream in a :ctype:`FILE\*` opened for
+   reading.  Only a 32-bit value can be read in using this function, regardless of
+   the native size of :ctype:`long`.
+
+
+.. cfunction:: int PyMarshal_ReadShortFromFile(FILE *file)
+
+   Return a C :ctype:`short` from the data stream in a :ctype:`FILE\*` opened for
+   reading.  Only a 16-bit value can be read in using this function, regardless of
+   the native size of :ctype:`short`.
+
+
+.. cfunction:: PyObject* PyMarshal_ReadObjectFromFile(FILE *file)
+
+   Return a Python object from the data stream in a :ctype:`FILE\*` opened for
+   reading.  On error, sets the appropriate exception (:exc:`EOFError` or
+   :exc:`TypeError`) and returns *NULL*.
+
+
+.. cfunction:: PyObject* PyMarshal_ReadLastObjectFromFile(FILE *file)
+
+   Return a Python object from the data stream in a :ctype:`FILE\*` opened for
+   reading.  Unlike :cfunc:`PyMarshal_ReadObjectFromFile`, this function assumes
+   that no further objects will be read from the file, allowing it to aggressively
+   load file data into memory so that the de-serialization can operate from data in
+   memory rather than reading a byte at a time from the file.  Only use these
+   variant if you are certain that you won't be reading anything else from the
+   file.  On error, sets the appropriate exception (:exc:`EOFError` or
+   :exc:`TypeError`) and returns *NULL*.
+
+
+.. cfunction:: PyObject* PyMarshal_ReadObjectFromString(char *string, Py_ssize_t len)
+
+   Return a Python object from the data stream in a character buffer containing
+   *len* bytes pointed to by *string*.  On error, sets the appropriate exception
+   (:exc:`EOFError` or :exc:`TypeError`) and returns *NULL*.
+
+
+.. _arg-parsing:
+
+Parsing arguments and building values
+=====================================
+
+These functions are useful when creating your own extensions functions and
+methods.  Additional information and examples are available in
+:ref:`extending-index`.
+
+The first three of these functions described, :cfunc:`PyArg_ParseTuple`,
+:cfunc:`PyArg_ParseTupleAndKeywords`, and :cfunc:`PyArg_Parse`, all use *format
+strings* which are used to tell the function about the expected arguments.  The
+format strings use the same syntax for each of these functions.
+
+A format string consists of zero or more "format units."  A format unit
+describes one Python object; it is usually a single character or a parenthesized
+sequence of format units.  With a few exceptions, a format unit that is not a
+parenthesized sequence normally corresponds to a single address argument to
+these functions.  In the following description, the quoted form is the format
+unit; the entry in (round) parentheses is the Python object type that matches
+the format unit; and the entry in [square] brackets is the type of the C
+variable(s) whose address should be passed.
+
+``s`` (string or Unicode object) [const char \*]
+   Convert a Python string or Unicode object to a C pointer to a character string.
+   You must not provide storage for the string itself; a pointer to an existing
+   string is stored into the character pointer variable whose address you pass.
+   The C string is NUL-terminated.  The Python string must not contain embedded NUL
+   bytes; if it does, a :exc:`TypeError` exception is raised. Unicode objects are
+   converted to C strings using the default encoding.  If this conversion fails, a
+   :exc:`UnicodeError` is raised.
+
+``s#`` (string, Unicode or any read buffer compatible object) [const char \*, int]
+   This variant on ``s`` stores into two C variables, the first one a pointer to a
+   character string, the second one its length.  In this case the Python string may
+   contain embedded null bytes.  Unicode objects pass back a pointer to the default
+   encoded string version of the object if such a conversion is possible.  All
+   other read-buffer compatible objects pass back a reference to the raw internal
+   data representation.
+
+``y`` (bytes object) [const char \*]
+   This variant on ``s`` convert a Python bytes object to a C pointer to a
+   character string. The bytes object must not contain embedded NUL bytes; if it
+   does, a :exc:`TypeError` exception is raised.
+
+``y#`` (bytes object) [const char \*, int]
+   This variant on ``s#`` stores into two C variables, the first one a pointer to a
+   character string, the second one its length.  This only accepts bytes objects.
+
+``z`` (string or ``None``) [const char \*]
+   Like ``s``, but the Python object may also be ``None``, in which case the C
+   pointer is set to *NULL*.
+
+``z#`` (string or ``None`` or any read buffer compatible object) [const char \*, int]
+   This is to ``s#`` as ``z`` is to ``s``.
+
+``u`` (Unicode object) [Py_UNICODE \*]
+   Convert a Python Unicode object to a C pointer to a NUL-terminated buffer of
+   16-bit Unicode (UTF-16) data.  As with ``s``, there is no need to provide
+   storage for the Unicode data buffer; a pointer to the existing Unicode data is
+   stored into the :ctype:`Py_UNICODE` pointer variable whose address you pass.
+
+``u#`` (Unicode object) [Py_UNICODE \*, int]
+   This variant on ``u`` stores into two C variables, the first one a pointer to a
+   Unicode data buffer, the second one its length. Non-Unicode objects are handled
+   by interpreting their read-buffer pointer as pointer to a :ctype:`Py_UNICODE`
+   array.
+
+``es`` (string, Unicode object or character buffer compatible object) [const char \*encoding, char \*\*buffer]
+   This variant on ``s`` is used for encoding Unicode and objects convertible to
+   Unicode into a character buffer. It only works for encoded data without embedded
+   NUL bytes.
+
+   This format requires two arguments.  The first is only used as input, and
+   must be a :ctype:`const char\*` which points to the name of an encoding as a
+   NUL-terminated string, or *NULL*, in which case the default encoding is used.
+   An exception is raised if the named encoding is not known to Python.  The
+   second argument must be a :ctype:`char\*\*`; the value of the pointer it
+   references will be set to a buffer with the contents of the argument text.
+   The text will be encoded in the encoding specified by the first argument.
+
+   :cfunc:`PyArg_ParseTuple` will allocate a buffer of the needed size, copy the
+   encoded data into this buffer and adjust *\*buffer* to reference the newly
+   allocated storage.  The caller is responsible for calling :cfunc:`PyMem_Free` to
+   free the allocated buffer after use.
+
+``et`` (string, Unicode object or character buffer compatible object) [const char \*encoding, char \*\*buffer]
+   Same as ``es`` except that 8-bit string objects are passed through without
+   recoding them.  Instead, the implementation assumes that the string object uses
+   the encoding passed in as parameter.
+
+``es#`` (string, Unicode object or character buffer compatible object) [const char \*encoding, char \*\*buffer, int \*buffer_length]
+   This variant on ``s#`` is used for encoding Unicode and objects convertible to
+   Unicode into a character buffer.  Unlike the ``es`` format, this variant allows
+   input data which contains NUL characters.
+
+   It requires three arguments.  The first is only used as input, and must be a
+   :ctype:`const char\*` which points to the name of an encoding as a
+   NUL-terminated string, or *NULL*, in which case the default encoding is used.
+   An exception is raised if the named encoding is not known to Python.  The
+   second argument must be a :ctype:`char\*\*`; the value of the pointer it
+   references will be set to a buffer with the contents of the argument text.
+   The text will be encoded in the encoding specified by the first argument.
+   The third argument must be a pointer to an integer; the referenced integer
+   will be set to the number of bytes in the output buffer.
+
+   There are two modes of operation:
+
+   If *\*buffer* points a *NULL* pointer, the function will allocate a buffer of
+   the needed size, copy the encoded data into this buffer and set *\*buffer* to
+   reference the newly allocated storage.  The caller is responsible for calling
+   :cfunc:`PyMem_Free` to free the allocated buffer after usage.
+
+   If *\*buffer* points to a non-*NULL* pointer (an already allocated buffer),
+   :cfunc:`PyArg_ParseTuple` will use this location as the buffer and interpret the
+   initial value of *\*buffer_length* as the buffer size.  It will then copy the
+   encoded data into the buffer and NUL-terminate it.  If the buffer is not large
+   enough, a :exc:`ValueError` will be set.
+
+   In both cases, *\*buffer_length* is set to the length of the encoded data
+   without the trailing NUL byte.
+
+``et#`` (string, Unicode object or character buffer compatible object) [const char \*encoding, char \*\*buffer]
+   Same as ``es#`` except that string objects are passed through without recoding
+   them. Instead, the implementation assumes that the string object uses the
+   encoding passed in as parameter.
+
+``b`` (integer) [char]
+   Convert a Python integer to a tiny int, stored in a C :ctype:`char`.
+
+``B`` (integer) [unsigned char]
+   Convert a Python integer to a tiny int without overflow checking, stored in a C
+   :ctype:`unsigned char`.
+
+   .. versionadded:: 2.3
+
+``h`` (integer) [short int]
+   Convert a Python integer to a C :ctype:`short int`.
+
+``H`` (integer) [unsigned short int]
+   Convert a Python integer to a C :ctype:`unsigned short int`, without overflow
+   checking.
+
+   .. versionadded:: 2.3
+
+``i`` (integer) [int]
+   Convert a Python integer to a plain C :ctype:`int`.
+
+``I`` (integer) [unsigned int]
+   Convert a Python integer to a C :ctype:`unsigned int`, without overflow
+   checking.
+
+   .. versionadded:: 2.3
+
+``l`` (integer) [long int]
+   Convert a Python integer to a C :ctype:`long int`.
+
+``k`` (integer) [unsigned long]
+   Convert a Python integer or long integer to a C :ctype:`unsigned long` without
+   overflow checking.
+
+   .. versionadded:: 2.3
+
+``L`` (integer) [PY_LONG_LONG]
+   Convert a Python integer to a C :ctype:`long long`.  This format is only
+   available on platforms that support :ctype:`long long` (or :ctype:`_int64` on
+   Windows).
+
+``K`` (integer) [unsigned PY_LONG_LONG]
+   Convert a Python integer or long integer to a C :ctype:`unsigned long long`
+   without overflow checking.  This format is only available on platforms that
+   support :ctype:`unsigned long long` (or :ctype:`unsigned _int64` on Windows).
+
+   .. versionadded:: 2.3
+
+``n`` (integer) [Py_ssize_t]
+   Convert a Python integer or long integer to a C :ctype:`Py_ssize_t`.
+
+   .. versionadded:: 2.5
+
+``c`` (string of length 1) [char]
+   Convert a Python character, represented as a string of length 1, to a C
+   :ctype:`char`.
+
+``f`` (float) [float]
+   Convert a Python floating point number to a C :ctype:`float`.
+
+``d`` (float) [double]
+   Convert a Python floating point number to a C :ctype:`double`.
+
+``D`` (complex) [Py_complex]
+   Convert a Python complex number to a C :ctype:`Py_complex` structure.
+
+``O`` (object) [PyObject \*]
+   Store a Python object (without any conversion) in a C object pointer.  The C
+   program thus receives the actual object that was passed.  The object's reference
+   count is not increased.  The pointer stored is not *NULL*.
+
+``O!`` (object) [*typeobject*, PyObject \*]
+   Store a Python object in a C object pointer.  This is similar to ``O``, but
+   takes two C arguments: the first is the address of a Python type object, the
+   second is the address of the C variable (of type :ctype:`PyObject\*`) into which
+   the object pointer is stored.  If the Python object does not have the required
+   type, :exc:`TypeError` is raised.
+
+``O&`` (object) [*converter*, *anything*]
+   Convert a Python object to a C variable through a *converter* function.  This
+   takes two arguments: the first is a function, the second is the address of a C
+   variable (of arbitrary type), converted to :ctype:`void \*`.  The *converter*
+   function in turn is called as follows::
+
+      status = converter(object, address);
+
+   where *object* is the Python object to be converted and *address* is the
+   :ctype:`void\*` argument that was passed to the :cfunc:`PyArg_Parse\*` function.
+   The returned *status* should be ``1`` for a successful conversion and ``0`` if
+   the conversion has failed.  When the conversion fails, the *converter* function
+   should raise an exception.
+
+``S`` (string) [PyStringObject \*]
+   Like ``O`` but requires that the Python object is a string object.  Raises
+   :exc:`TypeError` if the object is not a string object.  The C variable may also
+   be declared as :ctype:`PyObject\*`.
+
+``U`` (Unicode string) [PyUnicodeObject \*]
+   Like ``O`` but requires that the Python object is a Unicode object.  Raises
+   :exc:`TypeError` if the object is not a Unicode object.  The C variable may also
+   be declared as :ctype:`PyObject\*`.
+
+``t#`` (read-only character buffer) [char \*, int]
+   Like ``s#``, but accepts any object which implements the read-only buffer
+   interface.  The :ctype:`char\*` variable is set to point to the first byte of
+   the buffer, and the :ctype:`int` is set to the length of the buffer.  Only
+   single-segment buffer objects are accepted; :exc:`TypeError` is raised for all
+   others.
+
+``w`` (read-write character buffer) [char \*]
+   Similar to ``s``, but accepts any object which implements the read-write buffer
+   interface.  The caller must determine the length of the buffer by other means,
+   or use ``w#`` instead.  Only single-segment buffer objects are accepted;
+   :exc:`TypeError` is raised for all others.
+
+``w#`` (read-write character buffer) [char \*, int]
+   Like ``s#``, but accepts any object which implements the read-write buffer
+   interface.  The :ctype:`char \*` variable is set to point to the first byte of
+   the buffer, and the :ctype:`int` is set to the length of the buffer.  Only
+   single-segment buffer objects are accepted; :exc:`TypeError` is raised for all
+   others.
+
+``(items)`` (tuple) [*matching-items*]
+   The object must be a Python sequence whose length is the number of format units
+   in *items*.  The C arguments must correspond to the individual format units in
+   *items*.  Format units for sequences may be nested.
+
+   .. note::
+
+      Prior to Python version 1.5.2, this format specifier only accepted a tuple
+      containing the individual parameters, not an arbitrary sequence.  Code which
+      previously caused :exc:`TypeError` to be raised here may now proceed without an
+      exception.  This is not expected to be a problem for existing code.
+
+It is possible to pass Python long integers where integers are requested;
+however no proper range checking is done --- the most significant bits are
+silently truncated when the receiving field is too small to receive the value
+(actually, the semantics are inherited from downcasts in C --- your mileage may
+vary).
+
+A few other characters have a meaning in a format string.  These may not occur
+inside nested parentheses.  They are:
+
+``|``
+   Indicates that the remaining arguments in the Python argument list are optional.
+   The C variables corresponding to optional arguments should be initialized to
+   their default value --- when an optional argument is not specified,
+   :cfunc:`PyArg_ParseTuple` does not touch the contents of the corresponding C
+   variable(s).
+
+``:``
+   The list of format units ends here; the string after the colon is used as the
+   function name in error messages (the "associated value" of the exception that
+   :cfunc:`PyArg_ParseTuple` raises).
+
+``;``
+   The list of format units ends here; the string after the semicolon is used as
+   the error message *instead* of the default error message.  Clearly, ``:`` and
+   ``;`` mutually exclude each other.
+
+Note that any Python object references which are provided to the caller are
+*borrowed* references; do not decrement their reference count!
+
+Additional arguments passed to these functions must be addresses of variables
+whose type is determined by the format string; these are used to store values
+from the input tuple.  There are a few cases, as described in the list of format
+units above, where these parameters are used as input values; they should match
+what is specified for the corresponding format unit in that case.
+
+For the conversion to succeed, the *arg* object must match the format and the
+format must be exhausted.  On success, the :cfunc:`PyArg_Parse\*` functions
+return true, otherwise they return false and raise an appropriate exception.
+
+
+.. cfunction:: int PyArg_ParseTuple(PyObject *args, const char *format, ...)
+
+   Parse the parameters of a function that takes only positional parameters into
+   local variables.  Returns true on success; on failure, it returns false and
+   raises the appropriate exception.
+
+
+.. cfunction:: int PyArg_VaParse(PyObject *args, const char *format, va_list vargs)
+
+   Identical to :cfunc:`PyArg_ParseTuple`, except that it accepts a va_list rather
+   than a variable number of arguments.
+
+
+.. cfunction:: int PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *kw, const char *format, char *keywords[], ...)
+
+   Parse the parameters of a function that takes both positional and keyword
+   parameters into local variables.  Returns true on success; on failure, it
+   returns false and raises the appropriate exception.
+
+
+.. cfunction:: int PyArg_VaParseTupleAndKeywords(PyObject *args, PyObject *kw, const char *format, char *keywords[], va_list vargs)
+
+   Identical to :cfunc:`PyArg_ParseTupleAndKeywords`, except that it accepts a
+   va_list rather than a variable number of arguments.
+
+
+.. cfunction:: int PyArg_Parse(PyObject *args, const char *format, ...)
+
+   Function used to deconstruct the argument lists of "old-style" functions ---
+   these are functions which use the :const:`METH_OLDARGS` parameter parsing
+   method.  This is not recommended for use in parameter parsing in new code, and
+   most code in the standard interpreter has been modified to no longer use this
+   for that purpose.  It does remain a convenient way to decompose other tuples,
+   however, and may continue to be used for that purpose.
+
+
+.. cfunction:: int PyArg_UnpackTuple(PyObject *args, const char *name, Py_ssize_t min, Py_ssize_t max, ...)
+
+   A simpler form of parameter retrieval which does not use a format string to
+   specify the types of the arguments.  Functions which use this method to retrieve
+   their parameters should be declared as :const:`METH_VARARGS` in function or
+   method tables.  The tuple containing the actual parameters should be passed as
+   *args*; it must actually be a tuple.  The length of the tuple must be at least
+   *min* and no more than *max*; *min* and *max* may be equal.  Additional
+   arguments must be passed to the function, each of which should be a pointer to a
+   :ctype:`PyObject\*` variable; these will be filled in with the values from
+   *args*; they will contain borrowed references.  The variables which correspond
+   to optional parameters not given by *args* will not be filled in; these should
+   be initialized by the caller. This function returns true on success and false if
+   *args* is not a tuple or contains the wrong number of elements; an exception
+   will be set if there was a failure.
+
+   This is an example of the use of this function, taken from the sources for the
+   :mod:`_weakref` helper module for weak references::
+
+      static PyObject *
+      weakref_ref(PyObject *self, PyObject *args)
+      {
+          PyObject *object;
+          PyObject *callback = NULL;
+          PyObject *result = NULL;
+
+          if (PyArg_UnpackTuple(args, "ref", 1, 2, &object, &callback)) {
+              result = PyWeakref_NewRef(object, callback);
+          }
+          return result;
+      }
+
+   The call to :cfunc:`PyArg_UnpackTuple` in this example is entirely equivalent to
+   this call to :cfunc:`PyArg_ParseTuple`::
+
+      PyArg_ParseTuple(args, "O|O:ref", &object, &callback)
+
+   .. versionadded:: 2.2
+
+
+.. cfunction:: PyObject* Py_BuildValue(const char *format, ...)
+
+   Create a new value based on a format string similar to those accepted by the
+   :cfunc:`PyArg_Parse\*` family of functions and a sequence of values.  Returns
+   the value or *NULL* in the case of an error; an exception will be raised if
+   *NULL* is returned.
+
+   :cfunc:`Py_BuildValue` does not always build a tuple.  It builds a tuple only if
+   its format string contains two or more format units.  If the format string is
+   empty, it returns ``None``; if it contains exactly one format unit, it returns
+   whatever object is described by that format unit.  To force it to return a tuple
+   of size 0 or one, parenthesize the format string.
+
+   When memory buffers are passed as parameters to supply data to build objects, as
+   for the ``s`` and ``s#`` formats, the required data is copied.  Buffers provided
+   by the caller are never referenced by the objects created by
+   :cfunc:`Py_BuildValue`.  In other words, if your code invokes :cfunc:`malloc`
+   and passes the allocated memory to :cfunc:`Py_BuildValue`, your code is
+   responsible for calling :cfunc:`free` for that memory once
+   :cfunc:`Py_BuildValue` returns.
+
+   In the following description, the quoted form is the format unit; the entry in
+   (round) parentheses is the Python object type that the format unit will return;
+   and the entry in [square] brackets is the type of the C value(s) to be passed.
+
+   The characters space, tab, colon and comma are ignored in format strings (but
+   not within format units such as ``s#``).  This can be used to make long format
+   strings a tad more readable.
+
+   ``s`` (string) [char \*]
+      Convert a null-terminated C string to a Python object.  If the C string pointer
+      is *NULL*, ``None`` is used.
+
+   ``s#`` (string) [char \*, int]
+      Convert a C string and its length to a Python object.  If the C string pointer
+      is *NULL*, the length is ignored and ``None`` is returned.
+
+   ``z`` (string or ``None``) [char \*]
+      Same as ``s``.
+
+   ``z#`` (string or ``None``) [char \*, int]
+      Same as ``s#``.
+
+   ``u`` (Unicode string) [Py_UNICODE \*]
+      Convert a null-terminated buffer of Unicode (UCS-2 or UCS-4) data to a Python
+      Unicode object.  If the Unicode buffer pointer is *NULL*, ``None`` is returned.
+
+   ``u#`` (Unicode string) [Py_UNICODE \*, int]
+      Convert a Unicode (UCS-2 or UCS-4) data buffer and its length to a Python
+      Unicode object.   If the Unicode buffer pointer is *NULL*, the length is ignored
+      and ``None`` is returned.
+
+   ``U`` (string) [char \*]
+      Convert a null-terminated C string to a Python unicode object. If the C string
+      pointer is *NULL*, ``None`` is used.
+
+   ``U#`` (string) [char \*, int]
+      Convert a C string and its length to a Python unicode object. If the C string
+      pointer is *NULL*, the length is ignored and ``None`` is returned.
+
+   ``i`` (integer) [int]
+      Convert a plain C :ctype:`int` to a Python integer object.
+
+   ``b`` (integer) [char]
+      Convert a plain C :ctype:`char` to a Python integer object.
+
+   ``h`` (integer) [short int]
+      Convert a plain C :ctype:`short int` to a Python integer object.
+
+   ``l`` (integer) [long int]
+      Convert a C :ctype:`long int` to a Python integer object.
+
+   ``B`` (integer) [unsigned char]
+      Convert a C :ctype:`unsigned char` to a Python integer object.
+
+   ``H`` (integer) [unsigned short int]
+      Convert a C :ctype:`unsigned short int` to a Python integer object.
+
+   ``I`` (integer/long) [unsigned int]
+      Convert a C :ctype:`unsigned int` to a Python integer object or a Python long
+      integer object, if it is larger than ``sys.maxint``.
+
+   ``k`` (integer/long) [unsigned long]
+      Convert a C :ctype:`unsigned long` to a Python integer object or a Python long
+      integer object, if it is larger than ``sys.maxint``.
+
+   ``L`` (long) [PY_LONG_LONG]
+      Convert a C :ctype:`long long` to a Python long integer object. Only available
+      on platforms that support :ctype:`long long`.
+
+   ``K`` (long) [unsigned PY_LONG_LONG]
+      Convert a C :ctype:`unsigned long long` to a Python long integer object. Only
+      available on platforms that support :ctype:`unsigned long long`.
+
+   ``n`` (int) [Py_ssize_t]
+      Convert a C :ctype:`Py_ssize_t` to a Python integer or long integer.
+
+      .. versionadded:: 2.5
+
+   ``c`` (string of length 1) [char]
+      Convert a C :ctype:`int` representing a character to a Python string of length
+      1.
+
+   ``d`` (float) [double]
+      Convert a C :ctype:`double` to a Python floating point number.
+
+   ``f`` (float) [float]
+      Same as ``d``.
+
+   ``D`` (complex) [Py_complex \*]
+      Convert a C :ctype:`Py_complex` structure to a Python complex number.
+
+   ``O`` (object) [PyObject \*]
+      Pass a Python object untouched (except for its reference count, which is
+      incremented by one).  If the object passed in is a *NULL* pointer, it is assumed
+      that this was caused because the call producing the argument found an error and
+      set an exception. Therefore, :cfunc:`Py_BuildValue` will return *NULL* but won't
+      raise an exception.  If no exception has been raised yet, :exc:`SystemError` is
+      set.
+
+   ``S`` (object) [PyObject \*]
+      Same as ``O``.
+
+   ``N`` (object) [PyObject \*]
+      Same as ``O``, except it doesn't increment the reference count on the object.
+      Useful when the object is created by a call to an object constructor in the
+      argument list.
+
+   ``O&`` (object) [*converter*, *anything*]
+      Convert *anything* to a Python object through a *converter* function.  The
+      function is called with *anything* (which should be compatible with :ctype:`void
+      \*`) as its argument and should return a "new" Python object, or *NULL* if an
+      error occurred.
+
+   ``(items)`` (tuple) [*matching-items*]
+      Convert a sequence of C values to a Python tuple with the same number of items.
+
+   ``[items]`` (list) [*matching-items*]
+      Convert a sequence of C values to a Python list with the same number of items.
+
+   ``{items}`` (dictionary) [*matching-items*]
+      Convert a sequence of C values to a Python dictionary.  Each pair of consecutive
+      C values adds one item to the dictionary, serving as key and value,
+      respectively.
+
+   If there is an error in the format string, the :exc:`SystemError` exception is
+   set and *NULL* returned.
+
+
+.. _string-conversion:
+
+String conversion and formatting
+================================
+
+Functions for number conversion and formatted string output.
+
+
+.. cfunction:: int PyOS_snprintf(char *str, size_t size,  const char *format, ...)
+
+   Output not more than *size* bytes to *str* according to the format string
+   *format* and the extra arguments. See the Unix man page :manpage:`snprintf(2)`.
+
+
+.. cfunction:: int PyOS_vsnprintf(char *str, size_t size, const char *format, va_list va)
+
+   Output not more than *size* bytes to *str* according to the format string
+   *format* and the variable argument list *va*. Unix man page
+   :manpage:`vsnprintf(2)`.
+
+:cfunc:`PyOS_snprintf` and :cfunc:`PyOS_vsnprintf` wrap the Standard C library
+functions :cfunc:`snprintf` and :cfunc:`vsnprintf`. Their purpose is to
+guarantee consistent behavior in corner cases, which the Standard C functions do
+not.
+
+The wrappers ensure that *str*[*size*-1] is always ``'\0'`` upon return. They
+never write more than *size* bytes (including the trailing ``'\0'``) into str.
+Both functions require that ``str != NULL``, ``size > 0`` and ``format !=
+NULL``.
+
+If the platform doesn't have :cfunc:`vsnprintf` and the buffer size needed to
+avoid truncation exceeds *size* by more than 512 bytes, Python aborts with a
+*Py_FatalError*.
+
+The return value (*rv*) for these functions should be interpreted as follows:
+
+* When ``0 <= rv < size``, the output conversion was successful and *rv*
+  characters were written to *str* (excluding the trailing ``'\0'`` byte at
+  *str*[*rv*]).
+
+* When ``rv >= size``, the output conversion was truncated and a buffer with
+  ``rv + 1`` bytes would have been needed to succeed. *str*[*size*-1] is ``'\0'``
+  in this case.
+
+* When ``rv < 0``, "something bad happened." *str*[*size*-1] is ``'\0'`` in
+  this case too, but the rest of *str* is undefined. The exact cause of the error
+  depends on the underlying platform.
+
+The following functions provide locale-independent string to number conversions.
+
+
+.. cfunction:: double PyOS_ascii_strtod(const char *nptr, char **endptr)
+
+   Convert a string to a :ctype:`double`. This function behaves like the Standard C
+   function :cfunc:`strtod` does in the C locale. It does this without changing the
+   current locale, since that would not be thread-safe.
+
+   :cfunc:`PyOS_ascii_strtod` should typically be used for reading configuration
+   files or other non-user input that should be locale independent.
+
+   .. versionadded:: 2.4
+
+   See the Unix man page :manpage:`strtod(2)` for details.
+
+
+.. cfunction:: char * PyOS_ascii_formatd(char *buffer, size_t buf_len, const char *format, double d)
+
+   Convert a :ctype:`double` to a string using the ``'.'`` as the decimal
+   separator. *format* is a :cfunc:`printf`\ -style format string specifying the
+   number format. Allowed conversion characters are ``'e'``, ``'E'``, ``'f'``,
+   ``'F'``, ``'g'`` and ``'G'``.
+
+   The return value is a pointer to *buffer* with the converted string or NULL if
+   the conversion failed.
+
+   .. versionadded:: 2.4
+
+
+.. cfunction:: double PyOS_ascii_atof(const char *nptr)
+
+   Convert a string to a :ctype:`double` in a locale-independent way.
+
+   .. versionadded:: 2.4
+
+   See the Unix man page :manpage:`atof(2)` for details.
+
diff --git a/Doc/c-api/veryhigh.rst b/Doc/c-api/veryhigh.rst
new file mode 100644
index 0000000..4b26da6
--- /dev/null
+++ b/Doc/c-api/veryhigh.rst
@@ -0,0 +1,278 @@
+.. highlightlang:: c
+
+
+.. _veryhigh:
+
+*************************
+The Very High Level Layer
+*************************
+
+The functions in this chapter will let you execute Python source code given in a
+file or a buffer, but they will not let you interact in a more detailed way with
+the interpreter.
+
+Several of these functions accept a start symbol from the grammar as a
+parameter.  The available start symbols are :const:`Py_eval_input`,
+:const:`Py_file_input`, and :const:`Py_single_input`.  These are described
+following the functions which accept them as parameters.
+
+Note also that several of these functions take :ctype:`FILE\*` parameters.  On
+particular issue which needs to be handled carefully is that the :ctype:`FILE`
+structure for different C libraries can be different and incompatible.  Under
+Windows (at least), it is possible for dynamically linked extensions to actually
+use different libraries, so care should be taken that :ctype:`FILE\*` parameters
+are only passed to these functions if it is certain that they were created by
+the same library that the Python runtime is using.
+
+
+.. cfunction:: int Py_Main(int argc, char **argv)
+
+   The main program for the standard interpreter.  This is made available for
+   programs which embed Python.  The *argc* and *argv* parameters should be
+   prepared exactly as those which are passed to a C program's :cfunc:`main`
+   function.  It is important to note that the argument list may be modified (but
+   the contents of the strings pointed to by the argument list are not). The return
+   value will be the integer passed to the :func:`sys.exit` function, ``1`` if the
+   interpreter exits due to an exception, or ``2`` if the parameter list does not
+   represent a valid Python command line.
+
+
+.. cfunction:: int PyRun_AnyFile(FILE *fp, const char *filename)
+
+   This is a simplified interface to :cfunc:`PyRun_AnyFileExFlags` below, leaving
+   *closeit* set to ``0`` and *flags* set to *NULL*.
+
+
+.. cfunction:: int PyRun_AnyFileFlags(FILE *fp, const char *filename, PyCompilerFlags *flags)
+
+   This is a simplified interface to :cfunc:`PyRun_AnyFileExFlags` below, leaving
+   the *closeit* argument set to ``0``.
+
+
+.. cfunction:: int PyRun_AnyFileEx(FILE *fp, const char *filename, int closeit)
+
+   This is a simplified interface to :cfunc:`PyRun_AnyFileExFlags` below, leaving
+   the *flags* argument set to *NULL*.
+
+
+.. cfunction:: int PyRun_AnyFileExFlags(FILE *fp, const char *filename, int closeit, PyCompilerFlags *flags)
+
+   If *fp* refers to a file associated with an interactive device (console or
+   terminal input or Unix pseudo-terminal), return the value of
+   :cfunc:`PyRun_InteractiveLoop`, otherwise return the result of
+   :cfunc:`PyRun_SimpleFile`.  If *filename* is *NULL*, this function uses
+   ``"???"`` as the filename.
+
+
+.. cfunction:: int PyRun_SimpleString(const char *command)
+
+   This is a simplified interface to :cfunc:`PyRun_SimpleStringFlags` below,
+   leaving the *PyCompilerFlags\** argument set to NULL.
+
+
+.. cfunction:: int PyRun_SimpleStringFlags(const char *command, PyCompilerFlags *flags)
+
+   Executes the Python source code from *command* in the :mod:`__main__` module
+   according to the *flags* argument. If :mod:`__main__` does not already exist, it
+   is created.  Returns ``0`` on success or ``-1`` if an exception was raised.  If
+   there was an error, there is no way to get the exception information. For the
+   meaning of *flags*, see below.
+
+
+.. cfunction:: int PyRun_SimpleFile(FILE *fp, const char *filename)
+
+   This is a simplified interface to :cfunc:`PyRun_SimpleFileExFlags` below,
+   leaving *closeit* set to ``0`` and *flags* set to *NULL*.
+
+
+.. cfunction:: int PyRun_SimpleFileFlags(FILE *fp, const char *filename, PyCompilerFlags *flags)
+
+   This is a simplified interface to :cfunc:`PyRun_SimpleFileExFlags` below,
+   leaving *closeit* set to ``0``.
+
+
+.. cfunction:: int PyRun_SimpleFileEx(FILE *fp, const char *filename, int closeit)
+
+   This is a simplified interface to :cfunc:`PyRun_SimpleFileExFlags` below,
+   leaving *flags* set to *NULL*.
+
+
+.. cfunction:: int PyRun_SimpleFileExFlags(FILE *fp, const char *filename, int closeit, PyCompilerFlags *flags)
+
+   Similar to :cfunc:`PyRun_SimpleStringFlags`, but the Python source code is read
+   from *fp* instead of an in-memory string. *filename* should be the name of the
+   file.  If *closeit* is true, the file is closed before PyRun_SimpleFileExFlags
+   returns.
+
+
+.. cfunction:: int PyRun_InteractiveOne(FILE *fp, const char *filename)
+
+   This is a simplified interface to :cfunc:`PyRun_InteractiveOneFlags` below,
+   leaving *flags* set to *NULL*.
+
+
+.. cfunction:: int PyRun_InteractiveOneFlags(FILE *fp, const char *filename, PyCompilerFlags *flags)
+
+   Read and execute a single statement from a file associated with an interactive
+   device according to the *flags* argument.  If *filename* is *NULL*, ``"???"`` is
+   used instead.  The user will be prompted using ``sys.ps1`` and ``sys.ps2``.
+   Returns ``0`` when the input was executed successfully, ``-1`` if there was an
+   exception, or an error code from the :file:`errcode.h` include file distributed
+   as part of Python if there was a parse error.  (Note that :file:`errcode.h` is
+   not included by :file:`Python.h`, so must be included specifically if needed.)
+
+
+.. cfunction:: int PyRun_InteractiveLoop(FILE *fp, const char *filename)
+
+   This is a simplified interface to :cfunc:`PyRun_InteractiveLoopFlags` below,
+   leaving *flags* set to *NULL*.
+
+
+.. cfunction:: int PyRun_InteractiveLoopFlags(FILE *fp,  const char *filename, PyCompilerFlags *flags)
+
+   Read and execute statements from a file associated with an interactive device
+   until EOF is reached.  If *filename* is *NULL*, ``"???"`` is used instead.  The
+   user will be prompted using ``sys.ps1`` and ``sys.ps2``.  Returns ``0`` at EOF.
+
+
+.. cfunction:: struct _node* PyParser_SimpleParseString(const char *str, int start)
+
+   This is a simplified interface to
+   :cfunc:`PyParser_SimpleParseStringFlagsFilename` below, leaving  *filename* set
+   to *NULL* and *flags* set to ``0``.
+
+
+.. cfunction:: struct _node* PyParser_SimpleParseStringFlags( const char *str, int start, int flags)
+
+   This is a simplified interface to
+   :cfunc:`PyParser_SimpleParseStringFlagsFilename` below, leaving  *filename* set
+   to *NULL*.
+
+
+.. cfunction:: struct _node* PyParser_SimpleParseStringFlagsFilename( const char *str, const char *filename, int start, int flags)
+
+   Parse Python source code from *str* using the start token *start* according to
+   the *flags* argument.  The result can be used to create a code object which can
+   be evaluated efficiently. This is useful if a code fragment must be evaluated
+   many times.
+
+
+.. cfunction:: struct _node* PyParser_SimpleParseFile(FILE *fp, const char *filename, int start)
+
+   This is a simplified interface to :cfunc:`PyParser_SimpleParseFileFlags` below,
+   leaving *flags* set to ``0``
+
+
+.. cfunction:: struct _node* PyParser_SimpleParseFileFlags(FILE *fp, const char *filename, int start, int flags)
+
+   Similar to :cfunc:`PyParser_SimpleParseStringFlagsFilename`, but the Python
+   source code is read from *fp* instead of an in-memory string.
+
+
+.. cfunction:: PyObject* PyRun_String(const char *str, int start, PyObject *globals, PyObject *locals)
+
+   This is a simplified interface to :cfunc:`PyRun_StringFlags` below, leaving
+   *flags* set to *NULL*.
+
+
+.. cfunction:: PyObject* PyRun_StringFlags(const char *str, int start, PyObject *globals, PyObject *locals, PyCompilerFlags *flags)
+
+   Execute Python source code from *str* in the context specified by the
+   dictionaries *globals* and *locals* with the compiler flags specified by
+   *flags*.  The parameter *start* specifies the start token that should be used to
+   parse the source code.
+
+   Returns the result of executing the code as a Python object, or *NULL* if an
+   exception was raised.
+
+
+.. cfunction:: PyObject* PyRun_File(FILE *fp, const char *filename, int start, PyObject *globals, PyObject *locals)
+
+   This is a simplified interface to :cfunc:`PyRun_FileExFlags` below, leaving
+   *closeit* set to ``0`` and *flags* set to *NULL*.
+
+
+.. cfunction:: PyObject* PyRun_FileEx(FILE *fp, const char *filename, int start, PyObject *globals, PyObject *locals, int closeit)
+
+   This is a simplified interface to :cfunc:`PyRun_FileExFlags` below, leaving
+   *flags* set to *NULL*.
+
+
+.. cfunction:: PyObject* PyRun_FileFlags(FILE *fp, const char *filename, int start, PyObject *globals, PyObject *locals, PyCompilerFlags *flags)
+
+   This is a simplified interface to :cfunc:`PyRun_FileExFlags` below, leaving
+   *closeit* set to ``0``.
+
+
+.. cfunction:: PyObject* PyRun_FileExFlags(FILE *fp, const char *filename, int start, PyObject *globals, PyObject *locals, int closeit, PyCompilerFlags *flags)
+
+   Similar to :cfunc:`PyRun_StringFlags`, but the Python source code is read from
+   *fp* instead of an in-memory string. *filename* should be the name of the file.
+   If *closeit* is true, the file is closed before :cfunc:`PyRun_FileExFlags`
+   returns.
+
+
+.. cfunction:: PyObject* Py_CompileString(const char *str, const char *filename, int start)
+
+   This is a simplified interface to :cfunc:`Py_CompileStringFlags` below, leaving
+   *flags* set to *NULL*.
+
+
+.. cfunction:: PyObject* Py_CompileStringFlags(const char *str, const char *filename, int start, PyCompilerFlags *flags)
+
+   Parse and compile the Python source code in *str*, returning the resulting code
+   object.  The start token is given by *start*; this can be used to constrain the
+   code which can be compiled and should be :const:`Py_eval_input`,
+   :const:`Py_file_input`, or :const:`Py_single_input`.  The filename specified by
+   *filename* is used to construct the code object and may appear in tracebacks or
+   :exc:`SyntaxError` exception messages.  This returns *NULL* if the code cannot
+   be parsed or compiled.
+
+
+.. cvar:: int Py_eval_input
+
+   .. index:: single: Py_CompileString()
+
+   The start symbol from the Python grammar for isolated expressions; for use with
+   :cfunc:`Py_CompileString`.
+
+
+.. cvar:: int Py_file_input
+
+   .. index:: single: Py_CompileString()
+
+   The start symbol from the Python grammar for sequences of statements as read
+   from a file or other source; for use with :cfunc:`Py_CompileString`.  This is
+   the symbol to use when compiling arbitrarily long Python source code.
+
+
+.. cvar:: int Py_single_input
+
+   .. index:: single: Py_CompileString()
+
+   The start symbol from the Python grammar for a single statement; for use with
+   :cfunc:`Py_CompileString`. This is the symbol used for the interactive
+   interpreter loop.
+
+
+.. ctype:: struct PyCompilerFlags
+
+   This is the structure used to hold compiler flags.  In cases where code is only
+   being compiled, it is passed as ``int flags``, and in cases where code is being
+   executed, it is passed as ``PyCompilerFlags *flags``.  In this case, ``from
+   __future__ import`` can modify *flags*.
+
+   Whenever ``PyCompilerFlags *flags`` is *NULL*, :attr:`cf_flags` is treated as
+   equal to ``0``, and any modification due to ``from __future__ import`` is
+   discarded.  ::
+
+      struct PyCompilerFlags {
+          int cf_flags;
+      }
+
+
+.. cvar:: int CO_FUTURE_DIVISION
+
+   This bit can be set in *flags* to cause division operator ``/`` to be
+   interpreted as "true division" according to :pep:`238`.
+