[Patches] GC patch 3 and 4

Neil Schemenauer nascheme@enme.ucalgary.ca
Tue, 27 Jun 2000 19:41:36 -0600


On Wed, Jun 28, 2000 at 03:02:07AM +0200, Vladimir Marangozov wrote:
>    I'd suggest to officialize the following API -- better names are welcome:
> 
>    PyObject_FROM_GC(gp)  - returns a pointer to a Python object given a
>                            pointer to a GC_INFO struct. This is the current
>                            PyGC_INFO macro.
> 
>    PyObject_AS_GC(op)    - returns a pointer to a GC_INFO struct given an
>                            object pointer. This is the reverse macro
>                            (the current PyGC_OBJ macro)
> 
>    PyObject_GC_Init(op)  - init an object for GC (usually, at the end of the 
>                            constructor, cf. comments in objimpl.h)
> 
>    PyObject_GC_Fini(op)  - finalize an object subject to GC (usually, in the
>                            beginning of the destructor, cf. objimpl.h)
> 
>    BTW, I'd really prefer a more Pythonic name for GC_INFO, like GC_HEAD
>    as per Greg Stein's comments on these patches.

Those look fine to me.  The original names came mostly from code
by Guido.  Does anyone want to vote on this?  If not, I will use
the names Vladimir suggests.

> 2. Extension types that participate in GC
> 
>    The GC code implemented in the (core) object constructors is #ifdef'ed
>    which is not what one is expected to do for custom extension types.
>    If I am about to implement a GC'd type with the proposed patches, I'll
>    have to #ifdef things which is not really what I want.

Aren't extensions supposed to use the function APIs?  If so,
there are no ifdefs.

>    #ifdef WITH_CYCLE_GC
>    #define PyObject_FROM_GC(gp)  PyGC_INFO((PyGCInfo *)(gp))
>    #else
>    #define PyObject_FROM_GC(gp)  (gp)
>    #endif

Okay, I understand how you are thinking of getting rid of
PyObject_GC_DEL.  I will resubmit a patch with these changes.

  Neil

-- 
Real programmers don't make mistrakes