[Python-Dev] GC, flags, and subtyping (original) (raw)

Guido van Rossum guido@python.org
Fri, 05 Apr 2002 11:06:04 -0500

The issue of http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1041123 is back.

(BTW, the ASPN archives of python-dev are much prettier-looking than the pipermail ones, and they are searchable. Maybe Barry or Jeremy could update the list info to also point to the ASPN archives?)

I had removed PyTPFLAGSHAVEGC from my type, but as Thomas pointed out in http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1039576, the flag is set again by PyTypeReady(). That would be fine if the tpisgc field, which is initially zero in my metatype object, were copied automatically from its base (PyTYpeType). As it stands, my metatype is "forced" to inherit a claim that it handles GC, but the machinery for determining whether a given instance of the metatype is GC-able is /not/ inherited. Thus, my statically-allocated base instance is treated as though it was allocated by the GC mechanism.

Note that if a subtype provides its own tp_traverse and/or tp_clear, it does not inherit the HAVE_GC flag. (I'm not sure if this helps.)

This seems unneccessarily dangerous to me, and I propose that we change the semantics of type inheritance to inherit tpisgc by default.

Agreed. I think this was purely an oversight. Looking at the end of inherit_slots(), I notice that tp_new isn't inherited either -- I think that needs to be added to the list of inherited slots too.

Further, I think this points out the need for clarification of the subtyping mechanism. There should be one place where I can see which flags and tpxxx slots are inherited, what they mean, in addition to the answers to other mysteries hidden in typeobject.c et al. I'm willing to work something up, if I can get some guidance as to the most appropriate form. It's not clear to me that there's an appropriate place in the structure of the API docs (it's not even clear to me that the API docs are the right place for this).

The API docs are the right place.

If you hate LaTeX, you can write the docs as plain text and send them to the appropriate channels -- they will magically be turned into LaTeX. (Maybe you can give reST a try? I'm sure that at some point we'll need an automatic translator to py-doc-latex, so we might as well get started on that now.)

--Guido van Rossum (home page: http://www.python.org/~guido/)