| \chapter{Object Implementation Support \label{newTypes}} |
| |
| |
| This chapter describes the functions, types, and macros used when |
| defining new object types. |
| |
| |
| \section{Allocating Objects on the Heap |
| \label{allocating-objects}} |
| |
| \begin{cfuncdesc}{PyObject*}{_PyObject_New}{PyTypeObject *type} |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{PyVarObject*}{_PyObject_NewVar}{PyTypeObject *type, int size} |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{_PyObject_Del}{PyObject *op} |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{PyObject*}{PyObject_Init}{PyObject *op, |
| PyTypeObject *type} |
| Initialize a newly-allocated object \var{op} with its type and |
| initial reference. Returns the initialized object. If \var{type} |
| indicates that the object participates in the cyclic garbage |
| detector, it it added to the detector's set of observed objects. |
| Other fields of the object are not affected. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{PyVarObject*}{PyObject_InitVar}{PyVarObject *op, |
| PyTypeObject *type, int size} |
| This does everything \cfunction{PyObject_Init()} does, and also |
| initializes the length information for a variable-size object. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_New}{TYPE, PyTypeObject *type} |
| Allocate a new Python object using the C structure type \var{TYPE} |
| and the Python type object \var{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 \member{tp_basicsize} field of the |
| type object. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_NewVar}{TYPE, PyTypeObject *type, |
| int size} |
| Allocate a new Python object using the C structure type \var{TYPE} |
| and the Python type object \var{type}. Fields not defined by the |
| Python object header are not initialized. The allocated memory |
| allows for the \var{TYPE} structure plus \var{size} fields of the |
| size given by the \member{tp_itemsize} field of \var{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. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{PyObject_Del}{PyObject *op} |
| Releases memory allocated to an object using |
| \cfunction{PyObject_New()} or \cfunction{PyObject_NewVar()}. This |
| is normally called from the \member{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. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW}{TYPE, PyTypeObject *type} |
| Macro version of \cfunction{PyObject_New()}, to gain performance at |
| the expense of safety. This does not check \var{type} for a \NULL{} |
| value. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_NEW_VAR}{TYPE, PyTypeObject *type, |
| int size} |
| Macro version of \cfunction{PyObject_NewVar()}, to gain performance |
| at the expense of safety. This does not check \var{type} for a |
| \NULL{} value. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{PyObject_DEL}{PyObject *op} |
| Macro version of \cfunction{PyObject_Del()}. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{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. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{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 \var{doc} is non-\NULL, it will |
| be used to define the docstring for the module. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{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 \var{doc} is non-\NULL, it will |
| be used to define the docstring for the module. If \var{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 \var{apiver}, the only value which should |
| be passed is defined by the constant \constant{PYTHON_API_VERSION}. |
| |
| \note{Most uses of this function should probably be using |
| the \cfunction{Py_InitModule3()} instead; only use this if you are |
| sure you need it.} |
| \end{cfuncdesc} |
| |
| DL_IMPORT |
| |
| \begin{cvardesc}{PyObject}{_Py_NoneStruct} |
| Object which is visible in Python as \code{None}. This should only |
| be accessed using the \code{Py_None} macro, which evaluates to a |
| pointer to this object. |
| \end{cvardesc} |
| |
| |
| \section{Common Object Structures \label{common-structs}} |
| |
| 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. |
| |
| \begin{ctypedesc}{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 \code{PyObject_VAR_HEAD} macro. |
| \end{ctypedesc} |
| |
| \begin{ctypedesc}{PyVarObject} |
| This is an extension of \ctype{PyObject} that adds the |
| \member{ob_size} field. This is only used for objects that have |
| some notion of \emph{length}. This type does not often appear in |
| the Python/C API. It corresponds to the fields defined by the |
| expansion of the \code{PyObject_VAR_HEAD} macro. |
| \end{ctypedesc} |
| |
| These macros are used in the definition of \ctype{PyObject} and |
| \ctype{PyVarObject}: |
| |
| \begin{csimplemacrodesc}{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 depends on the definition of |
| \csimplemacro{Py_TRACE_REFS}. By default, that macro is not |
| defined, and \csimplemacro{PyObject_HEAD} expands to: |
| \begin{verbatim} |
| int ob_refcnt; |
| PyTypeObject *ob_type; |
| \end{verbatim} |
| When \csimplemacro{Py_TRACE_REFS} is defined, it expands to: |
| \begin{verbatim} |
| PyObject *_ob_next, *_ob_prev; |
| int ob_refcnt; |
| PyTypeObject *ob_type; |
| \end{verbatim} |
| \end{csimplemacrodesc} |
| |
| \begin{csimplemacrodesc}{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: |
| \begin{verbatim} |
| PyObject_HEAD |
| int ob_size; |
| \end{verbatim} |
| Note that \csimplemacro{PyObject_HEAD} is part of the expansion, and |
| that it's own expansion varies depending on the definition of |
| \csimplemacro{Py_TRACE_REFS}. |
| \end{csimplemacrodesc} |
| |
| PyObject_HEAD_INIT |
| |
| \begin{ctypedesc}{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. |
| \end{ctypedesc} |
| |
| \begin{ctypedesc}{PyMethodDef} |
| Structure used to describe a method of an extension type. This |
| structure has four fields: |
| |
| \begin{tableiii}{l|l|l}{member}{Field}{C Type}{Meaning} |
| \lineiii{ml_name}{char *}{name of the method} |
| \lineiii{ml_meth}{PyCFunction}{pointer to the C implementation} |
| \lineiii{ml_flags}{int}{flag bits indicating how the call should be |
| constructed} |
| \lineiii{ml_doc}{char *}{points to the contents of the docstring} |
| \end{tableiii} |
| \end{ctypedesc} |
| |
| The \member{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 \var{self} object. |
| |
| The \member{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 \constant{METH_VARARGS} and \constant{METH_KEYWORDS} can be |
| combined. Any of the calling convention flags can be combined with a |
| binding flag. |
| |
| \begin{datadesc}{METH_VARARGS} |
| This is the typical calling convention, where the methods have the |
| type \ctype{PyMethodDef}. The function expects two |
| \ctype{PyObject*} values. The first one is the \var{self} object for |
| methods; for module functions, it has the value given to |
| \cfunction{Py_InitModule4()} (or \NULL{} if |
| \cfunction{Py_InitModule()} was used). The second parameter |
| (often called \var{args}) is a tuple object representing all |
| arguments. This parameter is typically processed using |
| \cfunction{PyArg_ParseTuple()}. |
| \end{datadesc} |
| |
| \begin{datadesc}{METH_KEYWORDS} |
| Methods with these flags must be of type |
| \ctype{PyCFunctionWithKeywords}. The function expects three |
| parameters: \var{self}, \var{args}, and a dictionary of all the |
| keyword arguments. The flag is typically combined with |
| \constant{METH_VARARGS}, and the parameters are typically processed |
| using \cfunction{PyArg_ParseTupleAndKeywords()}. |
| \end{datadesc} |
| |
| \begin{datadesc}{METH_NOARGS} |
| Methods without parameters don't need to check whether arguments are |
| given if they are listed with the \constant{METH_NOARGS} flag. They |
| need to be of type \ctype{PyNoArgsFunction}: they expect a single |
| single \ctype{PyObject*} as a parameter. When used with object |
| methods, this parameter is typically named \code{self} and will hold |
| a reference to the object instance. |
| \end{datadesc} |
| |
| \begin{datadesc}{METH_O} |
| Methods with a single object argument can be listed with the |
| \constant{METH_O} flag, instead of invoking |
| \cfunction{PyArg_ParseTuple()} with a \code{"O"} argument. They have |
| the type \ctype{PyCFunction}, with the \var{self} parameter, and a |
| \ctype{PyObject*} parameter representing the single argument. |
| \end{datadesc} |
| |
| \begin{datadesc}{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. |
| \end{datadesc} |
| |
| 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. |
| |
| \begin{datadesc}{METH_CLASS} |
| The method will be passed the type object as the first parameter |
| rather than an instance of the type. This is used to create |
| \emph{class methods}, similar to what is created when using the |
| \function{classmethod()}\bifuncindex{classmethod} built-in |
| function. |
| \versionadded{2.3} |
| \end{datadesc} |
| |
| \begin{datadesc}{METH_STATIC} |
| The method will be passed \NULL{} as the first parameter rather than |
| an instance of the type. This is used to create \emph{static |
| methods}, similar to what is created when using the |
| \function{staticmethod()}\bifuncindex{staticmethod} built-in |
| function. |
| \versionadded{2.3} |
| \end{datadesc} |
| |
| |
| \begin{cfuncdesc}{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 |
| \member{tp_getattro} or \member{tp_getattr} handler that does not |
| use the \cfunction{PyObject_GenericGetAttr()} function. |
| \end{cfuncdesc} |
| |
| |
| \section{Type Objects \label{type-structs}} |
| |
| 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 \cfunction{PyObject_*()} or \cfunction{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: |
| |
| \verbatiminput{typestruct.h} |
| |
| The type object structure extends the \ctype{PyVarObject} structure, |
| though it does not actually need the the \member{ob_size} field. The |
| inclusion of this field is a historical accident that must be |
| maintained to ensure binary compatibility between new versions of |
| Python and older compiled extensions. |
| |
| \begin{cmemberdesc}{PyObject}{PyObject*}{_ob_next} |
| \cmemberline{PyObject}{PyObject*}{_ob_prev} |
| These fields are only present when the macro \code{Py_TRACE_REFS} is |
| defined. Their initialization to \NULL{} is taken care of by the |
| \code{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 \emph{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. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyObject}{int}{ob_refcnt} |
| This is the type object's reference count, initialized to \code{1} |
| by the \code{PyObject_HEAD_INIT} macro. Note that for statically |
| allocated type objects, the type's instances (objects whose |
| \member{ob_type} points back to the type) do \emph{not} count as |
| references. But for dynamically allocated type objects, the |
| instances \emph{do} count as references. |
| |
| This field is not inherited by subtypes. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyObject}{PyTypeObject*}{ob_type} |
| This is the type's type, in other words its metatype. It is |
| initialized by the argument to the \code{PyObject_HEAD_INIT} macro, |
| and its value should normally be \code{\&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 |
| \code{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: |
| |
| \begin{verbatim} |
| Foo_Type.ob_type = &PyType_Type; |
| \end{verbatim} |
| |
| This should be done before any instances of the type are created. |
| \cfunction{PyType_Ready()} checks if \member{ob_type} is \NULL, and |
| if so, initializes it: in Python 2.2, it is set to |
| \code{\&PyType_Type}; in Python 2.2.1 and later it will be |
| initialized to the \member{ob_type} field of the base class. |
| \cfunction{PyType_Ready()} will not change this field if it is |
| nonzero. |
| |
| 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. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyVarObject}{int}{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. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{char*}{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 \module{M} in subpackage \module{Q} in package \module{P} |
| should have the \member{tp_name} initializer \code{"P.Q.M.T"}. |
| |
| For dynamically allocated type objects, this may be just the type |
| name, if the module name is explicitly stored in the type dict as |
| the value for key \code{'__module__'}. |
| |
| If the tp_name field contains a dot, everything before the last dot |
| is made accessible as the \member{__module__} attribute, and |
| everything after the last dot is made accessible as the |
| \member{__name__} attribute. If no dot is present, the entire |
| \member{tp_name} field is made accessible as the \member{__name__} |
| attribute, and the \member{__module__} attribute is undefined |
| (unless explicitly set in the dictionary, as explained above). |
| |
| This field is not inherited by subtypes. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{int}{tp_basicsize} |
| \cmemberline{PyTypeObject}{int}{tp_itemsize} |
| These fields allow calculating the size in byte of instances of |
| the type. |
| |
| There are two kinds of types: types with fixed-length instances have |
| a zero \member{tp_itemsize} field, types with variable-length |
| instances have a non-zero \member{tp_itemsize} field. For a type |
| with fixed-length instances, all instances have the same size, |
| given in \member{tp_basicsize}. |
| |
| For a type with variable-length instances, the instances must have |
| an \member{ob_size} field, and the instance size is |
| \member{tp_basicsize} plus N times \member{tp_itemsize}, where N is |
| the ``length'' of the object. The value of N is typically stored in |
| the instance's \member{ob_size} field. There are exceptions: for |
| example, long ints use a negative \member{ob_size} to indicate a |
| negative number, and N is \code{abs(\member{ob_size})} there. Also, |
| the presence of an \member{ob_size} field in the instance layout |
| doesn't mean that the type is variable-length (for example, the list |
| type has fixed-length instances, yet those instances have a |
| meaningful \member{ob_size} field). |
| |
| The basic size includes the fields in the instance declared by the |
| macro \csimplemacro{PyObject_HEAD} or |
| \csimplemacro{PyObject_VAR_HEAD} (whichever is used to declare the |
| instance struct) and this in turn includes the \member{_ob_prev} and |
| \member{_ob_next} fields if they are present. This means that the |
| only correct way to get an initializer for the \member{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 \member{tp_basicsize}). |
| |
| These fields are inherited by subtypes. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{destructor}{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 \code{None} and |
| \code{Ellipsis}). |
| |
| The destructor function is called by the \cfunction{Py_DECREF()} and |
| \cfunction{Py_XDECREF()} macros when the new reference count is |
| zero. At this point, the instance is still in existance, 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 \member{tp_free} slot. If the type |
| is not subtypable (doesn't have the \constant{Py_TPFLAGS_BASETYPE} |
| flag bit set), it is permissible to call the object deallocator |
| directly instead of via \member{tp_free}. The object deallocator |
| should be the one used to allocate the instance; this is normally |
| \cfunction{PyObject_Del()} if the instance was allocated using |
| \cfunction{PyObject_New()} or \cfunction{PyOject_VarNew()}, or |
| \cfunction{PyObject_GC_Del()} if the instance was allocated using |
| \cfunction{PyObject_GC_New()} or \cfunction{PyObject_GC_VarNew()}. |
| |
| This field is inherited by subtypes. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{printfunc}{tp_print} |
| An optional pointer to the instance print function. |
| |
| The print function is only called when the instance is printed to a |
| \emph{real} file; when it is printed to a pseudo-file (like a |
| \class{StringIO} instance), the instance's \member{tp_repr} or |
| \member{tp_str} function is called to convert it to a string. These |
| are also called when the type's \member{tp_print} field is \NULL. |
| |
| The print function is called with the same signature as |
| \cfunction{PyObject_Print()}: \code{tp_print(PyObject *self, FILE |
| *file, int flags)}. The \var{self} argument is the instance to be |
| printed. The \var{file} argument is the stdio file to which it is |
| to be printed. The \var{flags} argument is composed of flag bits. |
| The only flag bit currently defined is \constant{Py_PRINT_RAW}. |
| When the \constant{Py_PRINT_RAW} flag bit is set, the instance |
| should be printed the same way as \member{tp_str} would format it; |
| when the \constant{Py_PRINT_RAW} flag bit is clear, the instance |
| should be printed the same was as \member{tp_repr} would format it. |
| |
| It is possible that the \member{tp_print} field will be deprecated. |
| In any case, it is recommended not to define \member{tp_print}, but |
| instead to rely on \member{tp_repr} and \member{tp_str} for |
| printing. |
| |
| This field is inherited by subtypes. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{getattrfunc}{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 \member{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 |
| \cfunction{PyObject_GetAttrString()}. |
| |
| This field is inherited by subtypes together with |
| \member{tp_getattro}: a subtype inherits both \member{tp_getattr} |
| and \member{tp_getattro} from its base type when the subtype's |
| \member{tp_getattr} and \member{tp_getattro} are both \NULL. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{setattrfunc}{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 \member{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 |
| \cfunction{PyObject_SetAttrString()}. |
| |
| This field is inherited by subtypes together with |
| \member{tp_setattro}: a subtype inherits both \member{tp_setattr} |
| and \member{tp_setattro} from its base type when the subtype's |
| \member{tp_setattr} and \member{tp_setattro} are both \NULL. |
| \end{cmemberdesc} |
| |
| \begin{cmemberdesc}{PyTypeObject}{cmpfunc}{tp_compare} |
| An optional pointer to the three-way comparison function. |
| |
| The signature is the same as for \cfunction{PyObject_Compare()}. |
| The function should return \code{1} if \var{self} greater than |
| \var{other}, \code{0} if \var{self} is equal to \var{other}, and |
| \code{-1} if \var{self} less than \var{other}. It should return |
| \code{-1} and set an exception condition when an error occurred |
| during the comparison. |
| |
| This field is inherited by subtypes together with |
| \member{tp_richcompare} and \member{tp_hash}: a subtypes inherits |
| all three of \member{tp_compare}, \member{tp_richcompare}, and |
| \member{tp_hash} when the subtype's \member{tp_compare}, |
| \member{tp_richcompare}, and \member{tp_hash} are all \NULL. |
| \end{cmemberdesc} |
| |
| |
| |
| \section{Mapping Object Structures \label{mapping-structs}} |
| |
| \begin{ctypedesc}{PyMappingMethods} |
| Structure used to hold pointers to the functions used to implement |
| the mapping protocol for an extension type. |
| \end{ctypedesc} |
| |
| |
| \section{Number Object Structures \label{number-structs}} |
| |
| \begin{ctypedesc}{PyNumberMethods} |
| Structure used to hold pointers to the functions an extension type |
| uses to implement the number protocol. |
| \end{ctypedesc} |
| |
| |
| \section{Sequence Object Structures \label{sequence-structs}} |
| |
| \begin{ctypedesc}{PySequenceMethods} |
| Structure used to hold pointers to the functions which an object |
| uses to implement the sequence protocol. |
| \end{ctypedesc} |
| |
| |
| \section{Buffer Object Structures \label{buffer-structs}} |
| \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 |
| \member{tp_as_buffer} member in the \ctype{PyTypeObject} structure |
| should be \NULL. Otherwise, the \member{tp_as_buffer} will point to |
| a \ctype{PyBufferProcs} structure. |
| |
| \note{It is very important that your \ctype{PyTypeObject} structure |
| uses \constant{Py_TPFLAGS_DEFAULT} for the value of the |
| \member{tp_flags} member rather than \code{0}. This tells the Python |
| runtime that your \ctype{PyBufferProcs} structure contains the |
| \member{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.} |
| |
| \begin{ctypedesc}{PyBufferProcs} |
| Structure used to hold the function pointers which define an |
| implementation of the buffer protocol. |
| |
| The first slot is \member{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 \member{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 \member{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. |
| |
| The last slot is \member{bf_getcharbuffer}, of type |
| \ctype{getcharbufferproc}. This slot will only be present if the |
| \constant{Py_TPFLAGS_HAVE_GETCHARBUFFER} flag is present in the |
| \member{tp_flags} field of the object's \ctype{PyTypeObject}. |
| Before using this slot, the caller should test whether it is present |
| by using the |
| \cfunction{PyType_HasFeature()}\ttindex{PyType_HasFeature()} |
| function. If present, it may be \NULL, indicating that the object's |
| contents cannot be used as \emph{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 |
| \member{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 |
| \var{N} does not mean there are \var{N} characters present.} |
| \end{ctypedesc} |
| |
| \begin{datadesc}{Py_TPFLAGS_HAVE_GETCHARBUFFER} |
| Flag bit set in the type structure to indicate that the |
| \member{bf_getcharbuffer} slot is known. This being set does not |
| indicate that the object supports the buffer interface or that the |
| \member{bf_getcharbuffer} slot is non-\NULL. |
| \end{datadesc} |
| |
| \begin{ctypedesc}[getreadbufferproc]{int (*getreadbufferproc) |
| (PyObject *self, int segment, void **ptrptr)} |
| Return a pointer to a readable segment of the buffer. This function |
| is allowed to raise an exception, in which case it must return |
| \code{-1}. The \var{segment} which is passed must be zero or |
| positive, and strictly less than the number of segments returned by |
| the \member{bf_getsegcount} slot function. On success, it returns |
| the length of the buffer memory, and sets \code{*\var{ptrptr}} to a |
| pointer to that memory. |
| \end{ctypedesc} |
| |
| \begin{ctypedesc}[getwritebufferproc]{int (*getwritebufferproc) |
| (PyObject *self, int segment, void **ptrptr)} |
| Return a pointer to a writable memory buffer in |
| \code{*\var{ptrptr}}, and the length of that segment as the function |
| return value. The memory buffer must correspond to buffer segment |
| \var{segment}. Must return \code{-1} and set an exception on |
| error. \exception{TypeError} should be raised if the object only |
| supports read-only buffers, and \exception{SystemError} should be |
| raised when \var{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. |
| \end{ctypedesc} |
| |
| \begin{ctypedesc}[getsegcountproc]{int (*getsegcountproc) |
| (PyObject *self, int *lenp)} |
| Return the number of memory segments which comprise the buffer. If |
| \var{lenp} is not \NULL, the implementation must report the sum of |
| the sizes (in bytes) of all segments in \code{*\var{lenp}}. |
| The function cannot fail. |
| \end{ctypedesc} |
| |
| \begin{ctypedesc}[getcharbufferproc]{int (*getcharbufferproc) |
| (PyObject *self, int segment, const char **ptrptr)} |
| \end{ctypedesc} |
| |
| |
| \section{Supporting the Iterator Protocol |
| \label{supporting-iteration}} |
| |
| |
| \section{Supporting Cyclic Garbarge Collection |
| \label{supporting-cycle-detection}} |
| |
| 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 |
| ``\ulink{Supporting the Cycle |
| Collector}{../ext/example-cycle-support.html}'' in |
| \citetitle[../ext/ext.html]{Extending and Embedding the Python |
| Interpreter}. |
| |
| To create a container type, the \member{tp_flags} field of the type |
| object must include the \constant{Py_TPFLAGS_HAVE_GC} and provide an |
| implementation of the \member{tp_traverse} handler. If instances of the |
| type are mutable, a \member{tp_clear} implementation must also be |
| provided. |
| |
| \begin{datadesc}{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. |
| \end{datadesc} |
| |
| Constructors for container types must conform to two rules: |
| |
| \begin{enumerate} |
| \item The memory for the object must be allocated using |
| \cfunction{PyObject_GC_New()} or \cfunction{PyObject_GC_VarNew()}. |
| |
| \item Once all the fields which may contain references to other |
| containers are initialized, it must call |
| \cfunction{PyObject_GC_Track()}. |
| \end{enumerate} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_GC_New}{TYPE, PyTypeObject *type} |
| Analogous to \cfunction{PyObject_New()} but for container objects with |
| the \constant{Py_TPFLAGS_HAVE_GC} flag set. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{\var{TYPE}*}{PyObject_GC_NewVar}{TYPE, PyTypeObject *type, |
| int size} |
| Analogous to \cfunction{PyObject_NewVar()} but for container objects |
| with the \constant{Py_TPFLAGS_HAVE_GC} flag set. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{PyVarObject *}{PyObject_GC_Resize}{PyVarObject *op, int} |
| Resize an object allocated by \cfunction{PyObject_NewVar()}. Returns |
| the resized object or \NULL{} on failure. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{PyObject_GC_Track}{PyObject *op} |
| Adds the object \var{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 \member{tp_traverse} handler become valid, |
| usually near the end of the constructor. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{_PyObject_GC_TRACK}{PyObject *op} |
| A macro version of \cfunction{PyObject_GC_Track()}. It should not be |
| used for extension modules. |
| \end{cfuncdesc} |
| |
| Similarly, the deallocator for the object must conform to a similar |
| pair of rules: |
| |
| \begin{enumerate} |
| \item Before fields which refer to other containers are invalidated, |
| \cfunction{PyObject_GC_UnTrack()} must be called. |
| |
| \item The object's memory must be deallocated using |
| \cfunction{PyObject_GC_Del()}. |
| \end{enumerate} |
| |
| \begin{cfuncdesc}{void}{PyObject_GC_Del}{PyObject *op} |
| Releases memory allocated to an object using |
| \cfunction{PyObject_GC_New()} or \cfunction{PyObject_GC_NewVar()}. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{PyObject_GC_UnTrack}{PyObject *op} |
| Remove the object \var{op} from the set of container objects tracked |
| by the collector. Note that \cfunction{PyObject_GC_Track()} can be |
| called again on this object to add it back to the set of tracked |
| objects. The deallocator (\member{tp_dealloc} handler) should call |
| this for the object before any of the fields used by the |
| \member{tp_traverse} handler become invalid. |
| \end{cfuncdesc} |
| |
| \begin{cfuncdesc}{void}{_PyObject_GC_UNTRACK}{PyObject *op} |
| A macro version of \cfunction{PyObject_GC_UnTrack()}. It should not be |
| used for extension modules. |
| \end{cfuncdesc} |
| |
| The \member{tp_traverse} handler accepts a function parameter of this |
| type: |
| |
| \begin{ctypedesc}[visitproc]{int (*visitproc)(PyObject *object, void *arg)} |
| Type of the visitor function passed to the \member{tp_traverse} |
| handler. The function should be called with an object to traverse |
| as \var{object} and the third parameter to the \member{tp_traverse} |
| handler as \var{arg}. |
| \end{ctypedesc} |
| |
| The \member{tp_traverse} handler must have the following type: |
| |
| \begin{ctypedesc}[traverseproc]{int (*traverseproc)(PyObject *self, |
| visitproc visit, void *arg)} |
| Traversal function for a container object. Implementations must |
| call the \var{visit} function for each object directly contained by |
| \var{self}, with the parameters to \var{visit} being the contained |
| object and the \var{arg} value passed to the handler. If |
| \var{visit} returns a non-zero value then an error has occurred and |
| that value should be returned immediately. |
| \end{ctypedesc} |
| |
| The \member{tp_clear} handler must be of the \ctype{inquiry} type, or |
| \NULL{} if the object is immutable. |
| |
| \begin{ctypedesc}[inquiry]{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 |
| \cfunction{Py_DECREF()} on a reference). The collector will call |
| this method if it detects that this object is involved in a |
| reference cycle. |
| \end{ctypedesc} |