[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4