[Python-Dev] debug and release python (original) (raw)

Amaury Forgeot d'Arc amauryfa at gmail.com
Tue Jun 15 22:24:05 CEST 2010

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 PYMALLOCDEBUG and WITHPYMALLOC 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 PyObjectDebugMalloc() 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 PYMALLOCDEBUG impolemented, that thunk to PyObjectMalloc et al. (This is what we have done at CCP) 2)      Remove the PyObjectDebugMalloc() from the api.  It really should be an implementation of in the exposed PyObjectMalloc() functions whether they use debug functionality at all.   the PyObjectDebugCheckAddress and PyObjectDebugDumpAddress() 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 PYMALLOCDEBUG) 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

More information about the Python-Dev mailing list