[2] | 1 | .. highlightlang:: c
|
---|
| 2 |
|
---|
| 3 | .. _common-structs:
|
---|
| 4 |
|
---|
| 5 | Common Object Structures
|
---|
| 6 | ========================
|
---|
| 7 |
|
---|
| 8 | There are a large number of structures which are used in the definition of
|
---|
| 9 | object types for Python. This section describes these structures and how they
|
---|
| 10 | are used.
|
---|
| 11 |
|
---|
| 12 | All Python objects ultimately share a small number of fields at the beginning
|
---|
| 13 | of the object's representation in memory. These are represented by the
|
---|
[391] | 14 | :c:type:`PyObject` and :c:type:`PyVarObject` types, which are defined, in turn,
|
---|
[2] | 15 | by the expansions of some macros also used, whether directly or indirectly, in
|
---|
| 16 | the definition of all other Python objects.
|
---|
| 17 |
|
---|
| 18 |
|
---|
[391] | 19 | .. c:type:: PyObject
|
---|
[2] | 20 |
|
---|
| 21 | All object types are extensions of this type. This is a type which
|
---|
| 22 | contains the information Python needs to treat a pointer to an object as an
|
---|
| 23 | object. In a normal "release" build, it contains only the object's
|
---|
| 24 | reference count and a pointer to the corresponding type object. It
|
---|
| 25 | corresponds to the fields defined by the expansion of the ``PyObject_HEAD``
|
---|
| 26 | macro.
|
---|
| 27 |
|
---|
| 28 |
|
---|
[391] | 29 | .. c:type:: PyVarObject
|
---|
[2] | 30 |
|
---|
[391] | 31 | This is an extension of :c:type:`PyObject` that adds the :attr:`ob_size`
|
---|
[2] | 32 | field. This is only used for objects that have some notion of *length*.
|
---|
| 33 | This type does not often appear in the Python/C API. It corresponds to the
|
---|
| 34 | fields defined by the expansion of the ``PyObject_VAR_HEAD`` macro.
|
---|
| 35 |
|
---|
[391] | 36 | These macros are used in the definition of :c:type:`PyObject` and
|
---|
| 37 | :c:type:`PyVarObject`:
|
---|
[2] | 38 |
|
---|
| 39 |
|
---|
[391] | 40 | .. c:macro:: PyObject_HEAD
|
---|
[2] | 41 |
|
---|
| 42 | This is a macro which expands to the declarations of the fields of the
|
---|
[391] | 43 | :c:type:`PyObject` type; it is used when declaring new types which represent
|
---|
[2] | 44 | objects without a varying length. The specific fields it expands to depend
|
---|
[391] | 45 | on the definition of :c:macro:`Py_TRACE_REFS`. By default, that macro is
|
---|
| 46 | not defined, and :c:macro:`PyObject_HEAD` expands to::
|
---|
[2] | 47 |
|
---|
| 48 | Py_ssize_t ob_refcnt;
|
---|
| 49 | PyTypeObject *ob_type;
|
---|
| 50 |
|
---|
[391] | 51 | When :c:macro:`Py_TRACE_REFS` is defined, it expands to::
|
---|
[2] | 52 |
|
---|
| 53 | PyObject *_ob_next, *_ob_prev;
|
---|
| 54 | Py_ssize_t ob_refcnt;
|
---|
| 55 | PyTypeObject *ob_type;
|
---|
| 56 |
|
---|
| 57 |
|
---|
[391] | 58 | .. c:macro:: PyObject_VAR_HEAD
|
---|
[2] | 59 |
|
---|
| 60 | This is a macro which expands to the declarations of the fields of the
|
---|
[391] | 61 | :c:type:`PyVarObject` type; it is used when declaring new types which
|
---|
[2] | 62 | represent objects with a length that varies from instance to instance.
|
---|
| 63 | This macro always expands to::
|
---|
| 64 |
|
---|
| 65 | PyObject_HEAD
|
---|
| 66 | Py_ssize_t ob_size;
|
---|
| 67 |
|
---|
[391] | 68 | Note that :c:macro:`PyObject_HEAD` is part of the expansion, and that its own
|
---|
| 69 | expansion varies depending on the definition of :c:macro:`Py_TRACE_REFS`.
|
---|
[2] | 70 |
|
---|
| 71 |
|
---|
[391] | 72 | .. c:macro:: PyObject_HEAD_INIT(type)
|
---|
[2] | 73 |
|
---|
| 74 | This is a macro which expands to initialization values for a new
|
---|
[391] | 75 | :c:type:`PyObject` type. This macro expands to::
|
---|
[2] | 76 |
|
---|
| 77 | _PyObject_EXTRA_INIT
|
---|
| 78 | 1, type,
|
---|
| 79 |
|
---|
| 80 |
|
---|
[391] | 81 | .. c:macro:: PyVarObject_HEAD_INIT(type, size)
|
---|
[2] | 82 |
|
---|
| 83 | This is a macro which expands to initialization values for a new
|
---|
[391] | 84 | :c:type:`PyVarObject` type, including the :attr:`ob_size` field.
|
---|
[2] | 85 | This macro expands to::
|
---|
| 86 |
|
---|
| 87 | _PyObject_EXTRA_INIT
|
---|
| 88 | 1, type, size,
|
---|
| 89 |
|
---|
| 90 |
|
---|
[391] | 91 | .. c:type:: PyCFunction
|
---|
[2] | 92 |
|
---|
| 93 | Type of the functions used to implement most Python callables in C.
|
---|
[391] | 94 | Functions of this type take two :c:type:`PyObject\*` parameters and return
|
---|
[2] | 95 | one such value. If the return value is *NULL*, an exception shall have
|
---|
| 96 | been set. If not *NULL*, the return value is interpreted as the return
|
---|
| 97 | value of the function as exposed in Python. The function must return a new
|
---|
| 98 | reference.
|
---|
| 99 |
|
---|
| 100 |
|
---|
[391] | 101 | .. c:type:: PyMethodDef
|
---|
[2] | 102 |
|
---|
| 103 | Structure used to describe a method of an extension type. This structure has
|
---|
| 104 | four fields:
|
---|
| 105 |
|
---|
| 106 | +------------------+-------------+-------------------------------+
|
---|
| 107 | | Field | C Type | Meaning |
|
---|
| 108 | +==================+=============+===============================+
|
---|
| 109 | | :attr:`ml_name` | char \* | name of the method |
|
---|
| 110 | +------------------+-------------+-------------------------------+
|
---|
| 111 | | :attr:`ml_meth` | PyCFunction | pointer to the C |
|
---|
| 112 | | | | implementation |
|
---|
| 113 | +------------------+-------------+-------------------------------+
|
---|
| 114 | | :attr:`ml_flags` | int | flag bits indicating how the |
|
---|
| 115 | | | | call should be constructed |
|
---|
| 116 | +------------------+-------------+-------------------------------+
|
---|
| 117 | | :attr:`ml_doc` | char \* | points to the contents of the |
|
---|
| 118 | | | | docstring |
|
---|
| 119 | +------------------+-------------+-------------------------------+
|
---|
| 120 |
|
---|
| 121 | The :attr:`ml_meth` is a C function pointer. The functions may be of different
|
---|
[391] | 122 | types, but they always return :c:type:`PyObject\*`. If the function is not of
|
---|
| 123 | the :c:type:`PyCFunction`, the compiler will require a cast in the method table.
|
---|
| 124 | Even though :c:type:`PyCFunction` defines the first parameter as
|
---|
| 125 | :c:type:`PyObject\*`, it is common that the method implementation uses a the
|
---|
[2] | 126 | specific C type of the *self* object.
|
---|
| 127 |
|
---|
| 128 | The :attr:`ml_flags` field is a bitfield which can include the following flags.
|
---|
| 129 | The individual flags indicate either a calling convention or a binding
|
---|
| 130 | convention. Of the calling convention flags, only :const:`METH_VARARGS` and
|
---|
| 131 | :const:`METH_KEYWORDS` can be combined (but note that :const:`METH_KEYWORDS`
|
---|
| 132 | alone is equivalent to ``METH_VARARGS | METH_KEYWORDS``). Any of the calling
|
---|
| 133 | convention flags can be combined with a binding flag.
|
---|
| 134 |
|
---|
| 135 |
|
---|
| 136 | .. data:: METH_VARARGS
|
---|
| 137 |
|
---|
| 138 | This is the typical calling convention, where the methods have the type
|
---|
[391] | 139 | :c:type:`PyCFunction`. The function expects two :c:type:`PyObject\*` values.
|
---|
| 140 | The first one is the *self* object for methods; for module functions, it is
|
---|
| 141 | the module object. The second parameter (often called *args*) is a tuple
|
---|
| 142 | object representing all arguments. This parameter is typically processed
|
---|
| 143 | using :c:func:`PyArg_ParseTuple` or :c:func:`PyArg_UnpackTuple`.
|
---|
[2] | 144 |
|
---|
| 145 |
|
---|
| 146 | .. data:: METH_KEYWORDS
|
---|
| 147 |
|
---|
[391] | 148 | Methods with these flags must be of type :c:type:`PyCFunctionWithKeywords`.
|
---|
[2] | 149 | The function expects three parameters: *self*, *args*, and a dictionary of
|
---|
| 150 | all the keyword arguments. The flag is typically combined with
|
---|
| 151 | :const:`METH_VARARGS`, and the parameters are typically processed using
|
---|
[391] | 152 | :c:func:`PyArg_ParseTupleAndKeywords`.
|
---|
[2] | 153 |
|
---|
| 154 |
|
---|
| 155 | .. data:: METH_NOARGS
|
---|
| 156 |
|
---|
| 157 | Methods without parameters don't need to check whether arguments are given if
|
---|
| 158 | they are listed with the :const:`METH_NOARGS` flag. They need to be of type
|
---|
[391] | 159 | :c:type:`PyCFunction`. The first parameter is typically named ``self`` and
|
---|
| 160 | will hold a reference to the module or object instance. In all cases the
|
---|
| 161 | second parameter will be *NULL*.
|
---|
[2] | 162 |
|
---|
| 163 |
|
---|
| 164 | .. data:: METH_O
|
---|
| 165 |
|
---|
| 166 | Methods with a single object argument can be listed with the :const:`METH_O`
|
---|
[391] | 167 | flag, instead of invoking :c:func:`PyArg_ParseTuple` with a ``"O"`` argument.
|
---|
| 168 | They have the type :c:type:`PyCFunction`, with the *self* parameter, and a
|
---|
| 169 | :c:type:`PyObject\*` parameter representing the single argument.
|
---|
[2] | 170 |
|
---|
| 171 |
|
---|
| 172 | .. data:: METH_OLDARGS
|
---|
| 173 |
|
---|
| 174 | This calling convention is deprecated. The method must be of type
|
---|
[391] | 175 | :c:type:`PyCFunction`. The second argument is *NULL* if no arguments are
|
---|
[2] | 176 | given, a single object if exactly one argument is given, and a tuple of
|
---|
| 177 | objects if more than one argument is given. There is no way for a function
|
---|
| 178 | using this convention to distinguish between a call with multiple arguments
|
---|
| 179 | and a call with a tuple as the only argument.
|
---|
| 180 |
|
---|
| 181 | These two constants are not used to indicate the calling convention but the
|
---|
| 182 | binding when use with methods of classes. These may not be used for functions
|
---|
| 183 | defined for modules. At most one of these flags may be set for any given
|
---|
| 184 | method.
|
---|
| 185 |
|
---|
| 186 |
|
---|
| 187 | .. data:: METH_CLASS
|
---|
| 188 |
|
---|
| 189 | .. index:: builtin: classmethod
|
---|
| 190 |
|
---|
| 191 | The method will be passed the type object as the first parameter rather
|
---|
| 192 | than an instance of the type. This is used to create *class methods*,
|
---|
| 193 | similar to what is created when using the :func:`classmethod` built-in
|
---|
| 194 | function.
|
---|
| 195 |
|
---|
| 196 | .. versionadded:: 2.3
|
---|
| 197 |
|
---|
| 198 |
|
---|
| 199 | .. data:: METH_STATIC
|
---|
| 200 |
|
---|
| 201 | .. index:: builtin: staticmethod
|
---|
| 202 |
|
---|
| 203 | The method will be passed *NULL* as the first parameter rather than an
|
---|
| 204 | instance of the type. This is used to create *static methods*, similar to
|
---|
| 205 | what is created when using the :func:`staticmethod` built-in function.
|
---|
| 206 |
|
---|
| 207 | .. versionadded:: 2.3
|
---|
| 208 |
|
---|
| 209 | One other constant controls whether a method is loaded in place of another
|
---|
| 210 | definition with the same method name.
|
---|
| 211 |
|
---|
| 212 |
|
---|
| 213 | .. data:: METH_COEXIST
|
---|
| 214 |
|
---|
| 215 | The method will be loaded in place of existing definitions. Without
|
---|
| 216 | *METH_COEXIST*, the default is to skip repeated definitions. Since slot
|
---|
| 217 | wrappers are loaded before the method table, the existence of a
|
---|
| 218 | *sq_contains* slot, for example, would generate a wrapped method named
|
---|
| 219 | :meth:`__contains__` and preclude the loading of a corresponding
|
---|
| 220 | PyCFunction with the same name. With the flag defined, the PyCFunction
|
---|
| 221 | will be loaded in place of the wrapper object and will co-exist with the
|
---|
| 222 | slot. This is helpful because calls to PyCFunctions are optimized more
|
---|
| 223 | than wrapper object calls.
|
---|
| 224 |
|
---|
| 225 | .. versionadded:: 2.4
|
---|
| 226 |
|
---|
| 227 |
|
---|
[391] | 228 | .. c:type:: PyMemberDef
|
---|
[2] | 229 |
|
---|
| 230 | Structure which describes an attribute of a type which corresponds to a C
|
---|
| 231 | struct member. Its fields are:
|
---|
| 232 |
|
---|
| 233 | +------------------+-------------+-------------------------------+
|
---|
| 234 | | Field | C Type | Meaning |
|
---|
| 235 | +==================+=============+===============================+
|
---|
| 236 | | :attr:`name` | char \* | name of the member |
|
---|
| 237 | +------------------+-------------+-------------------------------+
|
---|
| 238 | | :attr:`type` | int | the type of the member in the |
|
---|
| 239 | | | | C struct |
|
---|
| 240 | +------------------+-------------+-------------------------------+
|
---|
| 241 | | :attr:`offset` | Py_ssize_t | the offset in bytes that the |
|
---|
| 242 | | | | member is located on the |
|
---|
| 243 | | | | type's object struct |
|
---|
| 244 | +------------------+-------------+-------------------------------+
|
---|
| 245 | | :attr:`flags` | int | flag bits indicating if the |
|
---|
| 246 | | | | field should be read-only or |
|
---|
| 247 | | | | writable |
|
---|
| 248 | +------------------+-------------+-------------------------------+
|
---|
| 249 | | :attr:`doc` | char \* | points to the contents of the |
|
---|
| 250 | | | | docstring |
|
---|
| 251 | +------------------+-------------+-------------------------------+
|
---|
| 252 |
|
---|
| 253 | :attr:`type` can be one of many ``T_`` macros corresponding to various C
|
---|
| 254 | types. When the member is accessed in Python, it will be converted to the
|
---|
| 255 | equivalent Python type.
|
---|
| 256 |
|
---|
| 257 | =============== ==================
|
---|
| 258 | Macro name C type
|
---|
| 259 | =============== ==================
|
---|
| 260 | T_SHORT short
|
---|
| 261 | T_INT int
|
---|
| 262 | T_LONG long
|
---|
| 263 | T_FLOAT float
|
---|
| 264 | T_DOUBLE double
|
---|
| 265 | T_STRING char \*
|
---|
| 266 | T_OBJECT PyObject \*
|
---|
| 267 | T_OBJECT_EX PyObject \*
|
---|
| 268 | T_CHAR char
|
---|
| 269 | T_BYTE char
|
---|
| 270 | T_UBYTE unsigned char
|
---|
| 271 | T_UINT unsigned int
|
---|
| 272 | T_USHORT unsigned short
|
---|
| 273 | T_ULONG unsigned long
|
---|
| 274 | T_BOOL char
|
---|
| 275 | T_LONGLONG long long
|
---|
| 276 | T_ULONGLONG unsigned long long
|
---|
| 277 | T_PYSSIZET Py_ssize_t
|
---|
| 278 | =============== ==================
|
---|
| 279 |
|
---|
[391] | 280 | :c:macro:`T_OBJECT` and :c:macro:`T_OBJECT_EX` differ in that
|
---|
| 281 | :c:macro:`T_OBJECT` returns ``None`` if the member is *NULL* and
|
---|
| 282 | :c:macro:`T_OBJECT_EX` raises an :exc:`AttributeError`. Try to use
|
---|
| 283 | :c:macro:`T_OBJECT_EX` over :c:macro:`T_OBJECT` because :c:macro:`T_OBJECT_EX`
|
---|
[2] | 284 | handles use of the :keyword:`del` statement on that attribute more correctly
|
---|
[391] | 285 | than :c:macro:`T_OBJECT`.
|
---|
[2] | 286 |
|
---|
[391] | 287 | :attr:`flags` can be 0 for write and read access or :c:macro:`READONLY` for
|
---|
| 288 | read-only access. Using :c:macro:`T_STRING` for :attr:`type` implies
|
---|
| 289 | :c:macro:`READONLY`. Only :c:macro:`T_OBJECT` and :c:macro:`T_OBJECT_EX`
|
---|
[2] | 290 | members can be deleted. (They are set to *NULL*).
|
---|
| 291 |
|
---|
| 292 |
|
---|
[391] | 293 | .. c:function:: PyObject* Py_FindMethod(PyMethodDef table[], PyObject *ob, char *name)
|
---|
[2] | 294 |
|
---|
| 295 | Return a bound method object for an extension type implemented in C. This
|
---|
[391] | 296 | can be useful in the implementation of a :c:member:`~PyTypeObject.tp_getattro` or
|
---|
| 297 | :c:member:`~PyTypeObject.tp_getattr` handler that does not use the
|
---|
| 298 | :c:func:`PyObject_GenericGetAttr` function.
|
---|