[Python-Dev] Re: tp_clear return value (original) (raw)

Tim Peters tim.one@comcast.net
Wed, 09 Apr 2003 17:33:07 -0400

[Neil Schemenauer]

I was thinking that tpclear and tptraverse 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 tptraverse and tpclear should have returned "void".

[Martin v. Lowis]

While this is true for tpclear, tptraverse is actually more general. gc.getreferrers uses tptraverse, for something other than collection.

That would have made implementing those methods easier. Testing for errors in tptraverse methods is silly since nothing returns an error, and, even if it did, the GC couldn't handle it.

Again, gc.getreferrers "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 tptraverse 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