(original) (raw)

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.

Cheers,