[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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4