mirror of
https://github.com/python/cpython.git
synced 2025-11-03 23:21:29 +00:00
85 lines
3.1 KiB
C
85 lines
3.1 KiB
C
/* 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 */
|