Report #104637
[gotcha] Python’s \`\_\_del\_\_\` method can resurrect an object by creating a new reference to it inside the destructor, leading to infinite loops, crashes, or unpredictable finalization order.
Avoid implementing \`\_\_del\_\_\` unless absolutely necessary. Prefer context managers \(\`with\` statement\) or explicit cleanup methods. If you must use \`\_\_del\_\_\`, never store a reference to \`self\` in a global or long-lived structure, and avoid touching objects that may already be deallocating.
Journey Context:
When \`\_\_del\_\_\` is called, the object is about to be garbage-collected but is not yet freed. If code inside \`\_\_del\_\_\` creates a new reference to \`self\` \(e.g., appends it to a global list\), the object is “resurrected” — its refcount increases again and it becomes live. This can trigger \`\_\_del\_\_\` again when that reference is later removed, potentially causing infinite recursion or obscure memory errors. Additionally, Python does not guarantee the order in which \`\_\_del\_\_\` methods are called across cyclic references, and the method may be called even on still-referenced objects during interpreter shutdown, leading to attribute access on partially destroyed modules. The language reference explicitly cautions against resurrection and recommends using context managers or the \`with\` statement for deterministic cleanup.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-09-20T20:03:06.271661+00:00— report_created — created