[Python-Dev] Re: tp_clear return value
Wed, 09 Apr 2003 17:33:07 -0400
>> I was thinking that tp_clear and tp_traverse could somehow be used by
>> things other than the GC. In retrospect that doesn't seem likely or even
>> possible. The GC has pretty specific requirements.
>> In retrospect, I think both tp_traverse and tp_clear should have
>> returned "void".
[Martin v. Lowis]
> While this is true for tp_clear, tp_traverse is actually more general.
> gc.get_referrers uses tp_traverse, for something other than collection.
>> That would have made implementing those methods
>> easier. Testing for errors in tp_traverse methods is silly since
>> nothing returns an error, and, even if it did, the GC couldn't handle
> Again, gc.get_referrers "uses" this feature. If extending the list
> fails, traversal is aborted. Whether this is useful is questionable,
> as the entire notion of "out of memory exception handling" is
The brand new gc.get_referents uses the return value of tp_traverse to abort
on out-of-memory, but gc.get_referrers uses it for a different purpose (its
traversal function returns true if the visited object is in the tuple of
objects passed in, else returns false). The internal gc.get_referrers_for
is what aborts on out-of-memory in the get_referrers subsystem.
tp_traverse is fine as-is. The return value of tp_clear does indeed appear
without plausible use.
>> If we agree that, I volunteer to go through the code and remove the
>> useless tests for errors in the tp_traverse methods.
That would make get_referents press on after memory is exhausted. It would
also change the semantics of get_referrers, in a subtle way (if object A has
25 references to object B, gc.get_referrers(B) contains only 1 instance of A
today, but would contain 25 instances of A if tp_traverse methods ignored
visit() return values).
truth-isn't-necessarily-an-error-ly y'rs - tim