[Python-Dev] Re: tp_clear return value

[Tim Peters]

[Greg Ewing]
> A thought -- maybe tp_visit and tp_clear could be unified
> by having a tp_visit that passed pointers to pointers to
> objects to the callback?

I think Jeremy suggested something like that earlier today.  I don't think
it would fly now.  tuples are the simplest example of a gc container object
whose tp_clear and tp_traverse slot functions do radically different things
(the tuple tp_clear is NULL!); type objects may be the most complex example
(see the long comment block in typeobject.c's type_clear for an explanation
of why only tp_mro is-- or needs to be --cleared).  In general, tp_traverse
needs to reveal every PyObject* that may be part of a cycle, but tp_clear
only needs to nuke the subset of those necessary to guarantee that all
cycles will be broken.

OTOH, I suspect Guido thought too hard about this.  Like the tp_clear
comment:

	   tp_dict:
	       It is a dict, so the collector will call its tp_clear.

If type_clear decrefed tp_dict, and the refcount fell to 0 thereby, the
usual refcount mechanism would nuke the dict on its own, and the collector
would *not* in fact call the dict's tp_clear slot (the dict object would get
unlinked from the gc list it was in, and the collector would never see the
dict again).

So I'm unclear on what we're trying to optimize when a tp_clear nukes less
than the corresponding tp_traverse visits.  I suppose "code space" is one
decent answer to that.