[Python-Dev] Re: tp_clear return value

[Tim Peters]

[Neil Schemenauer]
>> 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
>> it.

> 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
> questionable.

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