> They're not trying very hard, then -- and, admittedly, most don't. > For example, every time the library grabs a resource that needs > finalization, it can plant a weakref to it in a singleton private > module object with a __del__ method... If you have to go through such convolutions to make __del__ methods reliable, perhaps some other mechanism should be provided in the first place. What you're describing sounds a lot like a scheme used in a Smalltalk system that I encountered once. Objects didn't have finalizing methods themselves; instead, an object could register another object as an "executor" to carry out its "last will and testament". This was done *after* the object in question had been deallocated, and after all other GC activity had finished, so there was no risk of resurrecting anything or getting the GC into a knot. Using weakrefs, it might be possible to implement something like this in pure Python, for use as an alternative to __del__ methods. > How? I believe this is beyond realistic automated analysis for Python > source. I wasn't suggesting that it be automated, I was suggesting that it be done explicitly. Suppose, e.g. there were a special attribute __dontclear__ which can be given a list of names of attributes that the GC shouldn't clear. The author of a __del__ method would then have to make sure that everything it needs is mentioned in that list, or risk having it disappear. > Even if we relied on programmers declaring their beliefs explicitly, > Python still has to be paranoid enough to avoid crashing if the > stated beliefs aren't really true. I can't see how a crash could result -- the worst that might happen is a __del__ method throws an exception because some attribute that it relies on has been cleared. That's then a programming error in that class -- the attribute should have been listed in __dontclear__. > You probably need also to detect that the finalizer can't resurrect > the object either, else clearing references that aren't needed > specifically for finalization would leave the resurrected object in > a damaged state. Or just refrain from writing __del__ methods that are silly enough to resurrect their objects. Or if resurrection really is necessary, put all their vital attributes in __dontclear__. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@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