Tim: > - weakref callbacks are easier to live with than __del__ methods in > one (and maybe only one) respect: when the death of X triggers > a weakref callback C, C isn't passed X, but X.__del__ is. So a > weakref callback can't resurrect X, but X.__del__ can. The object causing trouble doesn't need to be the one that died, e.g. doing a tp_clear on X causes Y to die which triggers a weakref callback which references X by some route. Resurrection of X isn't an issue, because it's not dead yet -- it is, however, in the process of being indiscriminately torn apart by the GC, messing up who-knows-what invariant that the callback might be relying on. So I can't see that the lack of possibility of resurrection helps much at all. > e.g., if it were always true that refcount-dropped-to-0 implies > can't-be-touched-again-by-Python-code, then what is it that gets > passed to x.__del__()? x does -- but we cheat But (I hope, at least!) it's guaranteed that the x.__del__() call is completed before any of the C-level deallocation code for x is begun... Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4