"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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4