PyMem_* cross-Python-generation recommendation?

[Michael Hudson]

"Mike C. Fletcher" <mcfletch at home.com> writes:

> From the Memory Interface document for Python 2.0, the following is
> described:
> 
> In addition, the following macro sets are provided for calling the Python
> memory allocator directly, without involving the C API functions listed
> above. However, note that their use does not preserve binary compatibility
> accross Python versions and is therefore deprecated in extension modules.
> 
> PyMem_MALLOC(), PyMem_REALLOC(), PyMem_FREE().
> PyMem_NEW(), PyMem_RESIZE(), PyMem_DEL().
> 
> 
> If I attempt to use PyMem_New in Python 1.5.2, I get a not-defined error,
> PyMem_NEW is there.  Conversely, if I attempt to use PyMem_FREE in 1.5.2, I
> get a not defined error but PyMem_Free is there.  So, I'm wondering, what
> combination should I use for an extension module (PyOpenGL) which requires
> compilation for both Python 1.5.2 and 2.x?  Currently I'm just using
> PyMem_NEW and PyMem_Free.  That compiles under both Pythons, but I have _no_
> clue what the implications of the choice are.

You probably want to use functions rather than macros (they have a
better chance of working across Python versions).  PyMem_NEW sounds
like a macro and PyMem_Free like a function, but this may not actually
be the case.

Are you talking about binary or source compatibility here?  I don't
know if binary compatibility works between 1.5.2 and 2.0 - I doubt it.
For source compatibility you can use #if hackery with
PYTHON_CAPI_VERSION to use the right one.

The interface is a bit of a mess pre-2.0, I believe.  You probably
want to use the 2.0 one if you can.

HTH, though I'm not sure it does,
M.

-- 
  While preceding your entrance with a grenade is a good tactic in
  Quake, it can lead to problems if attempted at work.    -- C Hacking
               -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html