[Python-Dev] Python 2.3 release schedule
29 May 2002 16:13:58 +0100
Neil Schemenauer <firstname.lastname@example.org> writes:
> Michael Hudson wrote:
> > I was under the impression that the 2.1 and 2.2 interfaces differed in
> > ways that couldn't easily be papered over with macros. I'll check.
> It's not pretty. Look at pyexpat.c for an example. Perhaps something
> like this would be good enough (untested):
> #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)
> People could then always use the 2.2 API but the objects would only be
> collected in versions >= 2.2. Using the 2.1 API is a fair bit trickier
> and you can't hide those differences using macros (although you could
> make it easier for people who want to support 2.1 and >=2.2).
Here's the latest effort:
/* this 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) */
/* 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).
PyMem_Malloc, PyMem_Realloc, PyMem_Free
PyObject_Malloc, PyObject_Realloc, PyObject_Free
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 lots of "small"
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
/* 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
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
#endif /* !Py_PYMEMCOMPAT_H */
Any final comments before I check it in? Particularly, I'd like Neil
to read the comments about the cycle collector.
I'll write on my monitor fifty times 'I must not post self-indulgent
wibble nobody is interested in to ucam.chat just because I'm bored
and I can't find the bug I'm supposed to fix'.
-- Steve Kitson, ucam.chat