"""
What do you think about the richer api I proposed here?
http://bugs.python.org/issue18835#msg232221
"""

msg232221:
"""
For numpy's purposes, I think the best approach would be to add a tracemalloc "escape valve", with an interface like:

PyMem_RecordAlloc(const char* domain, void* tag, size_t quantity, 
PyMem_RecordRealloc(const char* domain, void* old_tag, void* new_tag, size_t new_quantity)
PyMem_RecordFree(const char* domain, void* tag)
"""

I don't plan to store new information in tracemalloc. tracemalloc design is "simple": it stores a trace for each memory block. A memory block is identified by its address (void* pointer) and a trace is a tuple (size, traceback).

Extending a trace would increase the memory footprint overhead of tracemalloc.

Note: I don't understand what are domain, tag (address of the memory block?) or quantity (size of the memory block?).

Storing the C filename and C line number was proposed but rejected in the design of the PEP 445:
https://www.python.org/dev/peps/pep-0445/#pass-the-c-filename-and-line-number

I'm open to extending tracemalloc, but it requires to discuss the API and how changes will impact the code (tracemalloc, but also users of the tracemalloc API).