[Python-Dev] GC, flags, and subtyping

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 Py_TPFLAGS_HAVE_GC 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 PyType_Ready(). That would be fine if the
> tp_is_gc field, which is initially zero in my metatype object, were
> copied automatically from its base (PyTYpe_Type). 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 tp_is_gc 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 tp_xxx 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/)