I share the opinion of Floris on this: just because you link your application with python does not mean you want it to handle all memory management.

If you want the memory to be handled by Python, you should call PyMem_Malloc.

Otherwise people may want to use different malloc implementations in different parts of their application/libraries for different reasons (dmalloc for debugging http://dmalloc.com/ for example - we have seen that libffi bundles its own dlmalloc - someone may prefer a derivative of ptmalloc for performance reasons with threads...).

My application is linked with various libraries including libpython, glib and gmp, and I sometimes like to be able to distinguish how much memory is allocated by which library for profiling/debugging purpose for example.

I don't understand the point concerning trimming/fragmentation/threading by Charles-Francois: dlmalloc will allocate its own memory segment using mmap and handle memory inside that segment when you do a dlmalloc/dlfree/dlrealloc. Other malloc implementations will work in their own separate space and so won't impact or be impacted by what happens in dlmalloc segments.

dlmalloc is not that much different from pymalloc in that regard: it handles its own memory pool on top of the system memory implementations.
Yet you can have an application that uses the ordinary malloc while calling some Python code which uses pymalloc without any trimming/fragmentation/threading issues.