Jim Jewett <[EMAIL PROTECTED]> wrote: >>> I believe my example is a good use case for __del__ with no good >>> enough workaround, ... I still like the __close__ method being >>> proposed. > > [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? 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
