autoreload crashed on a module with __del__: interpreter error on reload

TL;DR

Exclude the del module from autoreload with %aimport so the interpreter never tries to reload it. Reloading a module with del finalizers can resurrect or double-finalize objects, which crashes the interpreter. Keep autoreload for your code, and restart the kernel when the finalizer module changes.

autoreload crashed on a module with __del__: interpreter error on reload

Use this when

• The kernel dies with an interpreter error right after autoreload processes a module
• The traceback or logs implicate del or object finalization
• Disabling autoreload stops the crash

Not for this skill when

• Autoreload ignores edits - that is item 128
• The module raises on import - that is an import problem
• The crash happens without autoreload - that is a general interpreter bug

Steps

1. Identify the module: enable autoreload with verbose logging or bisect by importing modules one at a time. Expected: one module consistently triggers the crash.

2. Confirm it defines del: search the module source. Expected: a del method on a class the module instantiates at import or keeps globally.

3. Exclude it: run %aimport -[module name] so autoreload skips it (list it explicitly if you use %aimport with includes). Expected: autoreload config shows the module excluded.

4. Restart the kernel once to clear any half-reloaded state. Expected: a clean kernel with no crash.

5. Re-enable %autoreload 2 and exercise the notebook. Expected: reloads work and the excluded module stays stable; restart the kernel when that module itself changes.

Tool compatibility

IPython 8.x, Python 3.9+

Variant phrasings

autoreload crashed module del

Same fix applies: see the Steps section above.

autoreload interpreter error on reload

Same fix applies: see the Steps section above.

%aimport exclude module autoreload crash

Same fix applies: see the Steps section above.

Why it happens

Reloading a module re-executes its top-level code, creating new class objects while old instances still exist. When those classes define del, the old and new finalizers can run against partially torn-down module state, and CPython's finalization during reload is fragile enough to segfault or raise fatal interpreter errors. Autoreload was designed for plain functions and classes; modules managing external resources with finalizers violate its assumptions. Excluding them is the supported escape hatch: %aimport exists precisely for modules autoreload cannot safely handle.

Edge cases / pitfalls

• del that only logs is usually safe; the crash needs real resource teardown in the finalizer.
• Excluding too broadly (whole packages) silently disables autoreload where you wanted it; exclude the single module.
• If the finalizer module changes often, the kernel-restart cost is real - consider moving the finalizer behind a factory function.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1qd22JhD5e-OjyHQ1KNoVA