Author vstinner
Recipients Yury.Selivanov, alecsandru.patrascu, catalin.manciu, jtaylor, pitrou, rhettinger, serhiy.storchaka, vstinner, yselivanov
Date 2016-03-09.14:44:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In february 2016, I started a thread on the python-dev mailing list:
[Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

M.-A. Lemburg wrote:


> Do you see any drawback of using pymalloc for PyMem_Malloc()?

Yes: You cannot free memory allocated using pymalloc with the
standard C lib free().

It would be better to go through the list of PyMem_*() calls
in Python and replace them with PyObject_*() calls, where

> Does anyone recall the rationale to have two families to memory allocators?

The PyMem_*() APIs were needed to have a cross-platform malloc()
implementation which returns standard C lib free()able memory,
but also behaves well when passing 0 as size.

M.-A. Lemburg fears that the PyMem_Malloc() API is misused:


Sometimes, yes, but we also do allocations for e.g.
parsing values in Python argument tuples (e.g. using
"es" or "et"):

We do document to use PyMem_Free() on those; not sure whether
everyone does this though.

M.-A. Lemburg suggested to the patch of this issue on:

Yes, but those are part of the stdlib. You'd need to check
a few C extensions which are not tested as part of the stdlib,
e.g. numpy, scipy, lxml, pillow, etc. (esp. ones which implement custom
types in C since these will often need the memory management

It may also be a good idea to check wrapper generators such
as cython, swig, cffi, etc.
Date User Action Args
2016-03-09 14:44:11vstinnersetrecipients: + vstinner, rhettinger, pitrou, Yury.Selivanov, jtaylor, serhiy.storchaka, yselivanov, alecsandru.patrascu, catalin.manciu
2016-03-09 14:44:11vstinnersetmessageid: <>
2016-03-09 14:44:11vstinnerlinkissue26249 messages
2016-03-09 14:44:10vstinnercreate