[Python-Dev] C new-style classes and GC (original) (raw)

Jim Fulton jim@zope.com
Fri, 16 May 2003 13:08:34 -0400

Jeremy Hylton wrote:

On Fri, 2003-05-16 at 11:46, Jim Fulton wrote:

So given that we have a new style type, to add support for GC, we need to:

- Set the PyTPFLAGSHAVEGC type flag, - Provide implementations of tptraverse and tpclear, as described in the section "Supporting the Cycle Collector" section of the docs. - Call PyObjectGCUnTrack at the beginning of the deallocator, before decrefing any members. I think that that is all we have to do. In particular, since we have a new style type that inherits the standard allocator, we don't need to fool with PyObjectGCNew, and PyObjectGCDEL, because the default tpalloc and tpfree take care of that for us. Similarly, we don't need to call PyObjectGCTrack, because that is done by the default allocator. (Because of that, our traverse function has to check for null object pointers in our object's members.) It depends on how the objects are used in C code. I've upgraded a lot of C extensions to make their types collectable recently. In several cases, it was necessary to change PyObjectNew to PyObjectGCNew and add a PyObjectGCTrack. I think the docs ought to explain how to do this.

If you write types the New Way, there are no PyObject_New calls and no need to call PyObject_GC_Track.

It's not clear to me what the one right way to implement a tpdealloc slot is. I've seen two common patterns in the Python source: call obj->obtype->tpfree or call PyObjectGCDel. The type object initializes tpfree to PyObjectGCDel, so in most cases the two spellings are equivalent. Calling PyObjectGCDel feels more straightforward to me.

You need to call obj->ob_type->tp_free to support subclassing.

I suggest that every new type should call obj->ob_type->tp_free as a matter of course.

Jim

-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (703) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org