[Python-Dev] Overwriting objects before deallocating them

Tim Peters tim.one@comcast.net
Fri, 24 May 2002 12:48:49 -0400


[Andrew]
> Is it worth trying to slowly fix it?  Picking a preferred name and
> making the interpreter's code use it consistently would be a start.

The pymalloc-for-2.3 changes are trying to make it possible for new programs
to use a much smaller set of memory API names.  Unfortunately, the
"recommended" set didn't include PyObject_Del (it recommended PyObject_Free
instead), because I wrote the recommendations.  That's unfortunate because
it only lasted until the first time Guido wrote new code <wink>.  So for 2.3
the recommended set grew again, to

    /* raw memory */
    PyMem_{Malloc, Realloc, Free}

    /* raw memory possibly using a different allocator than PyMem_ uses;
       biased towards lots of "small" allocations */
    PyObject_{Malloc, Realloc, Free}

    /* object memory; the allocators do some initialization as well
       as allocation; PyObject_Del is identical to PyObject_Free */
    PyObject_{New, NewVar, Del}

That's it.  There's really no reason in 2.3 to use anything else for non-gc
memory (including macro spellings!  they're almost always identical to the
function spellings in 2.3).

Under the covers, PyMem_Free in 2.3 is also identical to PyObject_{Free,
Del}, but that's a horrible backward compatibility hack I hope we can drop
some day (it costs runtime cycles).