[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