1.. highlight:: c 2 3.. _common-structs: 4 5Common Object Structures 6======================== 7 8There are a large number of structures which are used in the definition of 9object types for Python. This section describes these structures and how they 10are used. 11 12All Python objects ultimately share a small number of fields at the beginning 13of the object's representation in memory. These are represented by the 14:c:type:`PyObject` and :c:type:`PyVarObject` types, which are defined, in turn, 15by the expansions of some macros also used, whether directly or indirectly, in 16the definition of all other Python objects. 17 18 19.. c:type:: PyObject 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. 25 Nothing is actually declared to be a :c:type:`PyObject`, but every pointer 26 to a Python object can be cast to a :c:type:`PyObject*`. Access to the 27 members must be done by using the macros :c:macro:`Py_REFCNT` and 28 :c:macro:`Py_TYPE`. 29 30 31.. c:type:: PyVarObject 32 33 This is an extension of :c:type:`PyObject` that adds the :attr:`ob_size` 34 field. This is only used for objects that have some notion of *length*. 35 This type does not often appear in the Python/C API. 36 Access to the members must be done by using the macros 37 :c:macro:`Py_REFCNT`, :c:macro:`Py_TYPE`, and :c:macro:`Py_SIZE`. 38 39 40.. c:macro:: PyObject_HEAD 41 42 This is a macro used when declaring new types which represent objects 43 without a varying length. The PyObject_HEAD macro expands to:: 44 45 PyObject ob_base; 46 47 See documentation of :c:type:`PyObject` above. 48 49 50.. c:macro:: PyObject_VAR_HEAD 51 52 This is a macro used when declaring new types which represent objects 53 with a length that varies from instance to instance. 54 The PyObject_VAR_HEAD macro expands to:: 55 56 PyVarObject ob_base; 57 58 See documentation of :c:type:`PyVarObject` above. 59 60 61.. c:macro:: Py_TYPE(o) 62 63 This macro is used to access the :attr:`ob_type` member of a Python object. 64 It expands to:: 65 66 (((PyObject*)(o))->ob_type) 67 68 69.. c:macro:: Py_REFCNT(o) 70 71 This macro is used to access the :attr:`ob_refcnt` member of a Python 72 object. 73 It expands to:: 74 75 (((PyObject*)(o))->ob_refcnt) 76 77 78.. c:macro:: Py_SIZE(o) 79 80 This macro is used to access the :attr:`ob_size` member of a Python object. 81 It expands to:: 82 83 (((PyVarObject*)(o))->ob_size) 84 85 86.. c:macro:: PyObject_HEAD_INIT(type) 87 88 This is a macro which expands to initialization values for a new 89 :c:type:`PyObject` type. This macro expands to:: 90 91 _PyObject_EXTRA_INIT 92 1, type, 93 94 95.. c:macro:: PyVarObject_HEAD_INIT(type, size) 96 97 This is a macro which expands to initialization values for a new 98 :c:type:`PyVarObject` type, including the :attr:`ob_size` field. 99 This macro expands to:: 100 101 _PyObject_EXTRA_INIT 102 1, type, size, 103 104 105.. c:type:: PyCFunction 106 107 Type of the functions used to implement most Python callables in C. 108 Functions of this type take two :c:type:`PyObject\*` parameters and return 109 one such value. If the return value is ``NULL``, an exception shall have 110 been set. If not ``NULL``, the return value is interpreted as the return 111 value of the function as exposed in Python. The function must return a new 112 reference. 113 114 115.. c:type:: PyCFunctionWithKeywords 116 117 Type of the functions used to implement Python callables in C 118 with signature :const:`METH_VARARGS | METH_KEYWORDS`. 119 120 121.. c:type:: _PyCFunctionFast 122 123 Type of the functions used to implement Python callables in C 124 with signature :const:`METH_FASTCALL`. 125 126 127.. c:type:: _PyCFunctionFastWithKeywords 128 129 Type of the functions used to implement Python callables in C 130 with signature :const:`METH_FASTCALL | METH_KEYWORDS`. 131 132 133.. c:type:: PyMethodDef 134 135 Structure used to describe a method of an extension type. This structure has 136 four fields: 137 138 +------------------+---------------+-------------------------------+ 139 | Field | C Type | Meaning | 140 +==================+===============+===============================+ 141 | :attr:`ml_name` | const char \* | name of the method | 142 +------------------+---------------+-------------------------------+ 143 | :attr:`ml_meth` | PyCFunction | pointer to the C | 144 | | | implementation | 145 +------------------+---------------+-------------------------------+ 146 | :attr:`ml_flags` | int | flag bits indicating how the | 147 | | | call should be constructed | 148 +------------------+---------------+-------------------------------+ 149 | :attr:`ml_doc` | const char \* | points to the contents of the | 150 | | | docstring | 151 +------------------+---------------+-------------------------------+ 152 153The :attr:`ml_meth` is a C function pointer. The functions may be of different 154types, but they always return :c:type:`PyObject\*`. If the function is not of 155the :c:type:`PyCFunction`, the compiler will require a cast in the method table. 156Even though :c:type:`PyCFunction` defines the first parameter as 157:c:type:`PyObject\*`, it is common that the method implementation uses the 158specific C type of the *self* object. 159 160The :attr:`ml_flags` field is a bitfield which can include the following flags. 161The individual flags indicate either a calling convention or a binding 162convention. 163 164There are four basic calling conventions for positional arguments 165and two of them can be combined with :const:`METH_KEYWORDS` to support 166also keyword arguments. So there are a total of 6 calling conventions: 167 168.. data:: METH_VARARGS 169 170 This is the typical calling convention, where the methods have the type 171 :c:type:`PyCFunction`. The function expects two :c:type:`PyObject\*` values. 172 The first one is the *self* object for methods; for module functions, it is 173 the module object. The second parameter (often called *args*) is a tuple 174 object representing all arguments. This parameter is typically processed 175 using :c:func:`PyArg_ParseTuple` or :c:func:`PyArg_UnpackTuple`. 176 177 178.. data:: METH_VARARGS | METH_KEYWORDS 179 180 Methods with these flags must be of type :c:type:`PyCFunctionWithKeywords`. 181 The function expects three parameters: *self*, *args*, *kwargs* where 182 *kwargs* is a dictionary of all the keyword arguments or possibly ``NULL`` 183 if there are no keyword arguments. The parameters are typically processed 184 using :c:func:`PyArg_ParseTupleAndKeywords`. 185 186 187.. data:: METH_FASTCALL 188 189 Fast calling convention supporting only positional arguments. 190 The methods have the type :c:type:`_PyCFunctionFast`. 191 The first parameter is *self*, the second parameter is a C array 192 of :c:type:`PyObject\*` values indicating the arguments and the third 193 parameter is the number of arguments (the length of the array). 194 195 This is not part of the :ref:`limited API <stable>`. 196 197 .. versionadded:: 3.7 198 199 200.. data:: METH_FASTCALL | METH_KEYWORDS 201 202 Extension of :const:`METH_FASTCALL` supporting also keyword arguments, 203 with methods of type :c:type:`_PyCFunctionFastWithKeywords`. 204 Keyword arguments are passed the same way as in the vectorcall protocol: 205 there is an additional fourth :c:type:`PyObject\*` parameter 206 which is a tuple representing the names of the keyword arguments 207 or possibly ``NULL`` if there are no keywords. The values of the keyword 208 arguments are stored in the *args* array, after the positional arguments. 209 210 This is not part of the :ref:`limited API <stable>`. 211 212 .. versionadded:: 3.7 213 214 215.. data:: METH_NOARGS 216 217 Methods without parameters don't need to check whether arguments are given if 218 they are listed with the :const:`METH_NOARGS` flag. They need to be of type 219 :c:type:`PyCFunction`. The first parameter is typically named *self* and will 220 hold a reference to the module or object instance. In all cases the second 221 parameter will be ``NULL``. 222 223 224.. data:: METH_O 225 226 Methods with a single object argument can be listed with the :const:`METH_O` 227 flag, instead of invoking :c:func:`PyArg_ParseTuple` with a ``"O"`` argument. 228 They have the type :c:type:`PyCFunction`, with the *self* parameter, and a 229 :c:type:`PyObject\*` parameter representing the single argument. 230 231 232These two constants are not used to indicate the calling convention but the 233binding when use with methods of classes. These may not be used for functions 234defined for modules. At most one of these flags may be set for any given 235method. 236 237 238.. data:: METH_CLASS 239 240 .. index:: builtin: classmethod 241 242 The method will be passed the type object as the first parameter rather 243 than an instance of the type. This is used to create *class methods*, 244 similar to what is created when using the :func:`classmethod` built-in 245 function. 246 247 248.. data:: METH_STATIC 249 250 .. index:: builtin: staticmethod 251 252 The method will be passed ``NULL`` as the first parameter rather than an 253 instance of the type. This is used to create *static methods*, similar to 254 what is created when using the :func:`staticmethod` built-in function. 255 256One other constant controls whether a method is loaded in place of another 257definition with the same method name. 258 259 260.. data:: METH_COEXIST 261 262 The method will be loaded in place of existing definitions. Without 263 *METH_COEXIST*, the default is to skip repeated definitions. Since slot 264 wrappers are loaded before the method table, the existence of a 265 *sq_contains* slot, for example, would generate a wrapped method named 266 :meth:`__contains__` and preclude the loading of a corresponding 267 PyCFunction with the same name. With the flag defined, the PyCFunction 268 will be loaded in place of the wrapper object and will co-exist with the 269 slot. This is helpful because calls to PyCFunctions are optimized more 270 than wrapper object calls. 271 272 273.. c:type:: PyMemberDef 274 275 Structure which describes an attribute of a type which corresponds to a C 276 struct member. Its fields are: 277 278 +------------------+---------------+-------------------------------+ 279 | Field | C Type | Meaning | 280 +==================+===============+===============================+ 281 | :attr:`name` | const char \* | name of the member | 282 +------------------+---------------+-------------------------------+ 283 | :attr:`!type` | int | the type of the member in the | 284 | | | C struct | 285 +------------------+---------------+-------------------------------+ 286 | :attr:`offset` | Py_ssize_t | the offset in bytes that the | 287 | | | member is located on the | 288 | | | type's object struct | 289 +------------------+---------------+-------------------------------+ 290 | :attr:`flags` | int | flag bits indicating if the | 291 | | | field should be read-only or | 292 | | | writable | 293 +------------------+---------------+-------------------------------+ 294 | :attr:`doc` | const char \* | points to the contents of the | 295 | | | docstring | 296 +------------------+---------------+-------------------------------+ 297 298 :attr:`!type` can be one of many ``T_`` macros corresponding to various C 299 types. When the member is accessed in Python, it will be converted to the 300 equivalent Python type. 301 302 =============== ================== 303 Macro name C type 304 =============== ================== 305 T_SHORT short 306 T_INT int 307 T_LONG long 308 T_FLOAT float 309 T_DOUBLE double 310 T_STRING const char \* 311 T_OBJECT PyObject \* 312 T_OBJECT_EX PyObject \* 313 T_CHAR char 314 T_BYTE char 315 T_UBYTE unsigned char 316 T_UINT unsigned int 317 T_USHORT unsigned short 318 T_ULONG unsigned long 319 T_BOOL char 320 T_LONGLONG long long 321 T_ULONGLONG unsigned long long 322 T_PYSSIZET Py_ssize_t 323 =============== ================== 324 325 :c:macro:`T_OBJECT` and :c:macro:`T_OBJECT_EX` differ in that 326 :c:macro:`T_OBJECT` returns ``None`` if the member is ``NULL`` and 327 :c:macro:`T_OBJECT_EX` raises an :exc:`AttributeError`. Try to use 328 :c:macro:`T_OBJECT_EX` over :c:macro:`T_OBJECT` because :c:macro:`T_OBJECT_EX` 329 handles use of the :keyword:`del` statement on that attribute more correctly 330 than :c:macro:`T_OBJECT`. 331 332 :attr:`flags` can be ``0`` for write and read access or :c:macro:`READONLY` for 333 read-only access. Using :c:macro:`T_STRING` for :attr:`type` implies 334 :c:macro:`READONLY`. :c:macro:`T_STRING` data is interpreted as UTF-8. 335 Only :c:macro:`T_OBJECT` and :c:macro:`T_OBJECT_EX` 336 members can be deleted. (They are set to ``NULL``). 337 338 339.. c:type:: PyGetSetDef 340 341 Structure to define property-like access for a type. See also description of 342 the :c:member:`PyTypeObject.tp_getset` slot. 343 344 +-------------+------------------+-----------------------------------+ 345 | Field | C Type | Meaning | 346 +=============+==================+===================================+ 347 | name | const char \* | attribute name | 348 +-------------+------------------+-----------------------------------+ 349 | get | getter | C Function to get the attribute | 350 +-------------+------------------+-----------------------------------+ 351 | set | setter | optional C function to set or | 352 | | | delete the attribute, if omitted | 353 | | | the attribute is readonly | 354 +-------------+------------------+-----------------------------------+ 355 | doc | const char \* | optional docstring | 356 +-------------+------------------+-----------------------------------+ 357 | closure | void \* | optional function pointer, | 358 | | | providing additional data for | 359 | | | getter and setter | 360 +-------------+------------------+-----------------------------------+ 361 362 The ``get`` function takes one :c:type:`PyObject\*` parameter (the 363 instance) and a function pointer (the associated ``closure``):: 364 365 typedef PyObject *(*getter)(PyObject *, void *); 366 367 It should return a new reference on success or ``NULL`` with a set exception 368 on failure. 369 370 ``set`` functions take two :c:type:`PyObject\*` parameters (the instance and 371 the value to be set) and a function pointer (the associated ``closure``):: 372 373 typedef int (*setter)(PyObject *, PyObject *, void *); 374 375 In case the attribute should be deleted the second parameter is ``NULL``. 376 Should return ``0`` on success or ``-1`` with a set exception on failure. 377