[Python-Dev] Python 2.3 release schedule

[Michael Hudson]

Tim Peters <tim.one@comcast.net> writes:

> [Michael Hudson]
> > Writing a pymemcompat.h that people can bundle with their extensions
> > and then use the 2.3 memory interface with all Pythons in the range
> > 1.5.2 to 2.3.  I said I'd do this once the interface is settled, so
> > I'll try to get to it in the next week or so.  It shouldn't be *that*
> > hard...
> 
> I think that's a great idea!  Feel free to commandeer as much time from MAL
> and /F as you want, since they'll whine if it isn't done <wink>.

Surprise of the day: this:

#if PY_VERSION_HEX < 0x01060000
/* raw memory interface already present */

/* there is no object memory interface in 1.5.2 */
#define PyObject_Malloc(size) PyMem_Malloc((size))
#define PyObject_Realloc(p, size) PyMem_Realloc((p), (size))
#define PyObject_Free(p) PyMem_Free((p))

/* the object interface is there, but the names have changed */
#define PyObject_New(type, typeobj) \
                     PyObject_NEW((type), (typeobj))
#define PyObject_NewVar(type, typeobj, n) \
                     PyObject_NEW_VAR((type), (typeobj), (n))
#define PyObject_Del(ob) \
                     PyMem_Del((ob))

#endif

is all that's required!

Here's the full header I propose checking in to Misc/pymemcompat.h
(although the verbiage seems a bit excessive now).

/* 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) */

#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.

   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 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!  I.e. 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(size) PyMem_Malloc((size))
#define PyObject_Realloc(p, size) PyMem_Realloc((p), (size))
#define PyObject_Free(p) PyMem_Free((p))

/* the object interface is there, but the names have changed */
#define PyObject_New(type, typeobj) \
                     PyObject_NEW((type), (typeobj))
#define PyObject_NewVar(type, typeobj, n) \
                     PyObject_NEW_VAR((type), (typeobj), (n))
#define PyObject_Del(ob) \
                     PyMem_Del((ob))

#endif   

#endif /* !Py_PYMEMCOMPAT_H */

Comments, flames, etc appreciated.

Cheers,
M.

-- 
  But since I'm not trying to impress  anybody in The Software Big
  Top, I'd rather walk the wire using a big pole, a safety harness,
  a net, and with the wire not more than 3 feet off the ground.
                                   -- Grant Griffin, comp.lang.python