[Python-Dev] debug and release python

[Amaury Forgeot d'Arc]

2010/6/14 Kristján Valur Jónsson <kristjan at ccpgames.com>:
> Hello there.
>
> I‘m sure this has come up before, but here it is again:
>
>
>
> Python exports a different api in debug mode, depending on whether
> PYMALLOC_DEBUG and WITH_PYMALLOC are exported.  This means that _d.pyd files
> that are used must have been compiled with a version of python using the
> same settings for these macros.   It is unfortunate that the
> _PyObject_DebugMalloc() api is exposed to external applications using macros
> in objimpl.h
>
>
>
> I would suggest two things:
>
> 1)      provide dummy or thunking versions of those in builds that don‘t
> have PYMALLOC_DEBUG impolemented, that thunk to PyObject_Malloc et al. (This
> is what we have done at CCP)
>
> 2)      Remove the _PyObject_DebugMalloc() from the api.  It really should
> be an implementation of in the exposed PyObject_Malloc() functions whether
> they use debug functionality at all.   the _PyObject_DebugCheckAddress and
> _PyObject_DebugDumpAddress() can be left in place.  But exposing this
> functionality in macros that external moduled compile in, is not good at
> all.
>
> The reason why this is annoying:
>
> Some external software comes with proprietary .pyd bindings.  When
> developing my own application, with modified preprocessor definitions (e.g.
> to turn off PYMALLOC_DEBUG) we find that those externally provided libraries
> don‘t work.  It takes a fair amount of detective work to find out why
> exactly linkage fails.  The external API really shouldn‘t change depending
> on preprocessor definitions.

I remember having the same issue years ago:
http://mail.python.org/pipermail/python-list/2004-July/855844.html

At the time, I solved the issue by compiling extension modules with
pymalloc options turned on
(which it fortunately the default, so this applies to the supplied
proprietary .pyd),
and I added a (plain) definition for functions like _PyObject_DebugMalloc,
even when PYMALLOC_DEBUG is undefined.

Since the python_d.dll is a custom build anyway, adding the code is
not too much pain.

-- 
Amaury Forgeot d'Arc