| /* The idea of this file is that you bundle it with your extension, |
| #include it, program to Python 2.3's memory API and have your |
| extension build with any version of Python from 1.5.2 through to |
| 2.3 (and hopefully beyond). */ |
| |
| #ifndef Py_PYMEMCOMPAT_H |
| #define Py_PYMEMCOMPAT_H |
| |
| #include "Python.h" |
| |
| /* There are three "families" of memory API: the "raw memory", "object |
| memory" and "object" families. (This is ignoring the matter of the |
| cycle collector, about which more is said below). |
| |
| Raw Memory: |
| |
| PyMem_Malloc, PyMem_Realloc, PyMem_Free |
| |
| Object Memory: |
| |
| PyObject_Malloc, PyObject_Realloc, PyObject_Free |
| |
| Object: |
| |
| PyObject_New, PyObject_NewVar, PyObject_Del |
| |
| The raw memory and object memory allocators both mimic the |
| malloc/realloc/free interface from ANSI C, but the object memory |
| allocator can (and, since 2.3, does by default) use a different |
| allocation strategy biased towards lots of "small" allocations. |
| |
| The object family is used for allocating Python objects, and the |
| initializers take care of some basic initialization (setting the |
| refcount to 1 and filling out the ob_type field) as well as having |
| a somewhat different interface. |
| |
| Do not mix the families! E.g. do not allocate memory with |
| PyMem_Malloc and free it with PyObject_Free. You may get away with |
| it quite a lot of the time, but there *are* scenarios where this |
| will break. You Have Been Warned. |
| |
| Also, in many versions of Python there are an insane amount of |
| memory interfaces to choose from. Use the ones described above. */ |
| |
| #if PY_VERSION_HEX < 0x01060000 |
| /* raw memory interface already present */ |
| |
| /* there is no object memory interface in 1.5.2 */ |
| #define PyObject_Malloc PyMem_Malloc |
| #define PyObject_Realloc PyMem_Realloc |
| #define PyObject_Free PyMem_Free |
| |
| /* the object interface is there, but the names have changed */ |
| #define PyObject_New PyObject_NEW |
| #define PyObject_NewVar PyObject_NEW_VAR |
| #define PyObject_Del PyMem_Free |
| #endif |
| |
| /* If your object is a container you probably want to support the |
| cycle collector, which was new in Python 2.0. |
| |
| Unfortunately, the interface to the collector that was present in |
| Python 2.0 and 2.1 proved to be tricky to use, and so changed in |
| 2.2 -- in a way that can't easily be papered over with macros. |
| |
| This file contains macros that let you program to the 2.2 GC API. |
| Your module will compile against any Python since version 1.5.2, |
| but the type will only participate in the GC in versions 2.2 and |
| up. Some work is still necessary on your part to only fill out the |
| tp_traverse and tp_clear fields when they exist and set tp_flags |
| appropriately. |
| |
| It is possible to support both the 2.0 and 2.2 GC APIs, but it's |
| not pretty and this comment block is too narrow to contain a |
| desciption of what's required... */ |
| |
| #if PY_VERSION_HEX < 0x020200B1 |
| #define PyObject_GC_New PyObject_New |
| #define PyObject_GC_NewVar PyObject_NewVar |
| #define PyObject_GC_Del PyObject_Del |
| #define PyObject_GC_Track(op) |
| #define PyObject_GC_UnTrack(op) |
| #endif |
| |
| #endif /* !Py_PYMEMCOMPAT_H */ |