Mercurial > p > mysql-python > mysqldb-2
comparison pymemcompat.h @ 0:e48810735f11 MySQLdb
Copying 1.2.1 to be the new trunk
author | adustman |
---|---|
date | Sun, 02 Apr 2006 18:20:53 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
-1:000000000000 | 0:e48810735f11 |
---|---|
1 | |
2 /* The idea of this file is that you bundle it with your extension, | |
3 #include it, program to Python 2.3's memory API and have your | |
4 extension build with any version of Python from 1.5.2 through to | |
5 2.3 (and hopefully beyond). */ | |
6 | |
7 #ifndef Py_PYMEMCOMPAT_H | |
8 #define Py_PYMEMCOMPAT_H | |
9 | |
10 #include "Python.h" | |
11 | |
12 /* There are three "families" of memory API: the "raw memory", "object | |
13 memory" and "object" families. (This is ignoring the matter of the | |
14 cycle collector, about which more is said below). | |
15 | |
16 Raw Memory: | |
17 | |
18 PyMem_Malloc, PyMem_Realloc, PyMem_Free | |
19 | |
20 Object Memory: | |
21 | |
22 PyObject_Malloc, PyObject_Realloc, PyObject_Free | |
23 | |
24 Object: | |
25 | |
26 PyObject_New, PyObject_NewVar, PyObject_Del | |
27 | |
28 The raw memory and object memory allocators both mimic the | |
29 malloc/realloc/free interface from ANSI C, but the object memory | |
30 allocator can (and, since 2.3, does by default) use a different | |
31 allocation strategy biased towards lots of lots of "small" | |
32 allocations. | |
33 | |
34 The object family is used for allocating Python objects, and the | |
35 initializers take care of some basic initialization (setting the | |
36 refcount to 1 and filling out the ob_type field) as well as having | |
37 a somewhat different interface. | |
38 | |
39 Do not mix the families! E.g. do not allocate memory with | |
40 PyMem_Malloc and free it with PyObject_Free. You may get away with | |
41 it quite a lot of the time, but there *are* scenarios where this | |
42 will break. You Have Been Warned. | |
43 | |
44 Also, in many versions of Python there are an insane amount of | |
45 memory interfaces to choose from. Use the ones described above. */ | |
46 | |
47 #if PY_VERSION_HEX < 0x01060000 | |
48 /* raw memory interface already present */ | |
49 | |
50 /* there is no object memory interface in 1.5.2 */ | |
51 #define PyObject_Malloc PyMem_Malloc | |
52 #define PyObject_Realloc PyMem_Realloc | |
53 #define PyObject_Free PyMem_Free | |
54 | |
55 /* the object interface is there, but the names have changed */ | |
56 #define PyObject_New PyObject_NEW | |
57 #define PyObject_NewVar PyObject_NEW_VAR | |
58 #define PyObject_Del PyMem_Free | |
59 #endif | |
60 | |
61 /* If your object is a container you probably want to support the | |
62 cycle collector, which was new in Python 2.0. | |
63 | |
64 Unfortunately, the interface to the collector that was present in | |
65 Python 2.0 and 2.1 proved to be tricky to use, and so changed in | |
66 2.2 -- in a way that can't easily be papered over with macros. | |
67 | |
68 This file contains macros that let you program to the 2.2 GC API. | |
69 Your module will compile against any Python since version 1.5.2, | |
70 but the type will only participate in the GC in versions 2.2 and | |
71 up. Some work is still necessary on your part to only fill out the | |
72 tp_traverse and tp_clear fields when they exist and set tp_flags | |
73 appropriately. | |
74 | |
75 It is possible to support both the 2.0 and 2.2 GC APIs, but it's | |
76 not pretty and this comment block is too narrow to contain a | |
77 desciption of what's required... */ | |
78 | |
79 #if PY_VERSION_HEX < 0x020200B1 | |
80 #define PyObject_GC_New PyObject_New | |
81 #define PyObject_GC_NewVar PyObject_NewVar | |
82 #define PyObject_GC_Del PyObject_Del | |
83 #define PyObject_GC_Track(op) | |
84 #define PyObject_GC_UnTrack(op) | |
85 #endif | |
86 | |
87 #endif /* !Py_PYMEMCOMPAT_H */ |