[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