[Patches] GC patch 3 and 4

Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Thu, 29 Jun 2000 05:20:35 +0200 (CEST)


Neil Schemenauer wrote:
> 
> On Wed, Jun 28, 2000 at 06:33:10PM +0200, Vladimir Marangozov wrote:
> > BTW, what about the macro/function differenciation regarding the GC API?
> 
> I don't fully understand your question.  The GC API is as
> follows:

I asked because you know that code by heart, which is probably not my case,
and I wanted to be in sync with you. I haven't seen the need for API
function/macro pairs either (with their respective differences)...

> The major problem I see with the current API is that PyObject_NEW
> and PyObject_DEL are not symmetric.  When GC is enabled
> PyObject_NEW returns an object pointer while PyObject_DEL takes a
> GC pointer.

I see. Would it make sense for PyObject_NEW to return the GC pointer ?
(only if the object type supports GC). If so, it would be followed
systematically (for GC objects) by op = PyObject_FROM_GC(op), and we
get the symmetry.

We're talking about the macros after all. Extension types are not supposed
to use them. Only pre-1.6 extensions (may) use them, but they do not have GC.
Only the core + eventual customized extension types will use the macros,
whenever they inline these things, but then, if they want GC, they'll have
to convert the pointers explicitely after _NEW and before _DEL.

In the normal use cases, the functions, _New and _Del perform the
conversions automatically.

This pb comes from the fact that only a subset of the objects are GC'd
but we want to use the same API for all objects. The above is probably a
good compromise.

All this really boils down to what you've implemented from the start, i.e.
have PyObject_GC_NEW and _GC_DEL, but there are no _GC_New and _GC_Del
function equivalents and this is most probably the cause of my original
gripe about _GC_NEW and _GC_DEL ...

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252