• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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