Guido van Rossum wrote: > > OK, so we're down to this one point: if __del__ resurrects the object, > should __del__ be called again later? Additionally, should > resurrection be made illegal? Yes and no :-) One example comes to mind: implementations of weak references, which manage weak object references themselves (as soon as __del__ is called the weak reference implementation takes over the object). Another example is that of free list like implementations which reduce object creation times by implementing smart object recycling, e.g. objects could keep allocated dictionaries alive or connections to databases open, etc. As for the second point: Calling __del__ again is certainly needed to keep application logic sane... after all, __del__ should be called whenever the refcount reaches 0 -- and that can happend more than once in the objects life-time if reanimation occurs. > I can easily see how __del__ could *accidentally* resurrect the object > as part of its normal cleanup -- e.g. you make a call to some other > routine that helps with the cleanup, passing self as an argument, and > this other routine keeps a helpful cache of the last argument for some > reason. I don't see how we could forbid this type of resurrection. > (What are you going to do? You can't raise an exception from > instance_dealloc, since it is called from DECREF. You can't track > down the reference and replace it with a None easily.) > In this example, the helper routine will eventually delete the object > from its cache, at which point it is truly deleted. It would be > harmful, not helpful, if __del__ was called again at this point. I'd say this is an application logic error -- nothing that the mechanism itself can help with automagically. OTOH, turning multi calls to __del__ off, would make certain techniques impossible. > Now, it is true that the current docs for __del__ imply that > resurrection is possible. The intention of that note was to warn > __del__ writers that in the case of accidental resurrection __del__ > might be called again. The intention certainly wasn't to allow or > encourage intentional resurrection. I don't think that docs are the right argument here ;-) It is simply the reference counting logic that plays its role: __del__ is called when refcount reaches 0, which usually means that the object is about to be garbage collected... unless the object is rereferenced by some other object and thus gets reanimated. > Would there really be someone out there who uses *intentional* > resurrection? I severely doubt it. I've never heard of this. BTW, I can't see what the original question has to do with this discussion ... calling __del__ only after successful __init__ is ok, IMHO, but what does this have to do with the way __del__ itself is implemented ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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