Neil Schemenauer <nas@python.ca> writes: > 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
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