Raymond Hettinger wrote: > In short, __del__ should disappear not because it is useless but > because > it is hazardous. The consenting adults philosophy means that we don't > put-up artificial barriers to intentional hacks, but it does not mean > that we bait the hook and leave error-prone traps for the unwary. In > Py3k, I would like to see explicit finalization as a preferred > approach > and for weakrefs be the one-way-to-do-it for designs with implicit > finalization.
Raymond, there is one thing I don't understand in your line of reasoning. You say that you prefer explicit finalization, but that implicit finalization still needs to be supported. And for that, you'd rather drop __del__ and use weakrefs. But why? You say that __del__ is harardous, but I can't see how weakrefs are less hazardous. As an implicit finalization method, they live on the fragile assumption that the callback won't hold a reference to the object: an assumption which cannot be enforced in any way but cautious programming and scrupolous auditing of the code. I assert that they hide bugs much better than __del__ does (it's pretty easy to find an offending __del__ by looking at gc.garbage, while it's harder to notice a missing finalization because the cycle loop involving the weakref callback was broken at the wrong point). I guess there's something escaping me. If we have to drop one, why is that __del__? And if __del__ could be fixed to reliably work in reference cycles, would you still want to drop it? Giovanni Bajo _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
