[encukou]

• Issue: Add _DuringGC functions for tp_traverse #145921

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #35367398 | 📁 Comparing c8f1f2a against main (8d11920)

  🔍 Preview build  

17 files changed · ± 17 modified

± Modified

• builtins/functions.html
• c-api/gcsupport.html
• c-api/pyexpat.html
• deprecations/index.html
• deprecations/pending-removal-in-3.19.html
• deprecations/pending-removal-in-future.html
• library/concurrent.futures.html
• library/datetime.html
• library/json.html
• library/re.html
• and 7 more...

[nascheme]

LTGM aside from the "unreachable" wording.

[nascheme]

I would say something like "garbage reference cycles will not be broken and the program may waste memory". If you want to use to word "unreachable", I would say something like "the GC will not reliability determine which objects are unreachable and are only alive due to circular references"

[nascheme]

Or maybe more precisely "garbage reference cycles involving the skipped strong references will not be reliably broken". I think that's accurate. The GC will still be able to break up cyclic garbage involving the working tp_traverse methods (i.e. one failing tp_traverse doesn't prevent the cyclic GC from functioning entirely, which could be wrongly inferred). OTOH, maybe we want to be careful about promising too much. As the GC is now, it's true that other garbage reference cycles can be broken, even in the face of some tp_traverse methods not revealing all strong references. But maybe that's too strong of a promise.

[encukou]

I think we can guarantee that. If one incorrect tp_traverse could gum up the entire garbage collector, we'd have a big problem.
Also, “involving” isn't a very precise term...