--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/symbian-qemu-0.9.1-12/python-2.6.1/Misc/pymemcompat.h	Fri Jul 31 15:01:17 2009 +0100
@@ -0,0 +1,85 @@
+/* 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 */