Re: [Python-Dev] Mixing memory management APIs
Neil Schemenauer
Michael Hudson wrote:
Modified Files: _curses_panel.c Log Message: Oh look, another one.
2.2.1 candiate (he says, largely talking to himself :)
*** 192,196 **** Py_DECREF(po->wo); remove_lop(po); ! PyMem_DEL(po); }
--- 192,196 ---- Py_DECREF(po->wo); remove_lop(po); ! PyObject_DEL(po); }
I think we have to break down and do what Tim suggests. Ie make:
free == PyMem_DEL == PyObject_DEL == PyObject_FREE == ...
pymalloc needs to use a completely new set of APIs. The only problem I see is coming up with names. NEW, MALLOC, REALLOC, RESIZE, and DEL are all taken. Any suggestions?
And then change all the current uses of PyObject_Del to the new API? What would that buy us? Unless I misunderstand we *have* to do something different to remove an object as opposed to freeing raw storage (GC, for example). I agree we have too many preprocessor macros, but I don't think we can have free == PyObject_DEL. I don't what we have is so bad; a helpful tip is that if you're using the _Free/_FREE/_Malloc/_REALLOC/etc interfaces, stop. That gets rid of half the problem. Cheers, M. -- We've had a lot of problems going from glibc 2.0 to glibc 2.1. People claim binary compatibility. Except for functions they don't like. -- Peter Van Eynde, comp.lang.lisp
participants (5)
-
M.-A. Lemburg
-
Michael Hudson
-
Neal Norwitz
-
Neil Schemenauer
-
Tim Peters