[Python-Dev] Mixing memory management APIs

[Michael Hudson]

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