mirror of https://github.com/python/cpython
Remove outdated compatibility file.
This commit is contained in:
parent
00c6b62939
commit
0592be8f60
|
@ -1,85 +0,0 @@
|
|||
/* 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
|
||||
description 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 */
|
Loading…
Reference in New Issue