Giovanni Bajo wrote: > Is that easier or harder to detect such a cycle, compared to accidentally > adding a reference to self (through implicit nested scopes, or bound > methods) in the finalizer callback?
I would put a notice in the docs strongly recommending that only global functions be registered as finalizers, not nested functions or bound methods. While not strictly necessary (or sufficient) for safety, following this guideline would greatly reduce the chance of accidentally creating troublesome cycles, I think. And if you did accidentally create such a cycle, it seems to me it would be much easier to fix than if you were using __del__, since you only need to make an adjustment to the parameter list of the finalizer. With __del__, you need to refactor your whole finalization strategy and create another object to do the finalization, which is a much bigger upheaval. > Most finalization APIs (including yours) create > cycles just by using them, which also mean that you *must* wait for the GC > to kick in before the object is finalized No, a weakref-based finalizer will kick in just as soon as __del__ would. I don't know what makes you think otherwise. > will absolutely not solve the problem per-se: the user will > still have to pay attention and understand the hoops Certainly, but it will make it much more obvious that the hoops are there in the first place, and exactly where and what shape they are. > So, why do we not spend this same time trying to > *fix* __del__ instead? So far nobody has found a *way* to fix __del__ (really fix it, that is, not just paper over the cracks). And a lot of smart people have given it a lot of thought over the years. If someone comes up with a way some day, we can always put __del__ back in. But I don't feel like holding my breath waiting for that to happen, when we have something else that we know will work. >> # Use closure to get at weakref to allow direct invocation >> # This creates a cycle, so this approach relies on cyclic GC >> # to clean up the finalizer objects! This implementation is broken. There's no need to create any such cycle. -- Greg _______________________________________________ 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
