|  | /* 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 */ |