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

```text
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