[Python-3000] Removing __del__

[Giovanni Bajo]

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
>>> 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