[Python-3000] Removing __del__
rasky at develer.com
Thu Sep 21 01:00:32 CEST 2006
Jim Jewett <jimjjewett at gmail.com> wrote:
>>> I believe my example is a good use case for __del__ with no good
>>> enough workaround, ... I still like the __close__ method being
> [Michael asks about this alternative]
>> def on_del_invoke(obj, func, *args, **kwargs):
>> Please note that the callable must not be a bound method
>> of the object being watched, and the object being watched
>> must not be (or be refered to by) one of the arguments
>> or else the object will never be garbage collected."""
> By far the most frequently desired callable is self.close
> You can work around this with a wrapper, by setting self.f=open(...)
> and then passing self.f.close -- but with this API, I'll be wondering
> why I can't just register self.f as the object in the first place.
> If bound methods did not increment the refcount, this would work, but
> I imagine it would break various GUI and event-processing idioms.
> A special rebind-this-method-weakly builtin would work, but I'm not
> sure that is any simpler than __close__. (~= __del__ but cycles can
> be broken in an arbitrary order)
I once wrote a simple weakref wrapper, which binds methods weakly (it's pretty
easy to write). I thought it would have been dramatically useful one day, and I
still have to use it once :) And yes, I agree that __close__ is a much easier
solution to the problem.
> Note that the wrapper (as posted) does nothing except store a pointer
> to the CAPI object and then delegate to it. With a __close__ method,
> this class could reduce to (at most)
> class MyCAPI(CAPI):
> __close__ = close
Ehm, can a class be derived from a module?
More information about the Python-3000