[Python-3000] Removing __del__

Nick Coghlan ncoghlan at gmail.com
Thu Sep 21 12:31:25 CEST 2006

Michael Chermside wrote:
> Nick Coghlan writes:
>    [...proposes revision of __del__ rather than removal...]
>> The only way for __del__ to receive a reference to self is if the 
>> finalizer argument had a reference to it - but that would mean the 
>> object itself was not
>> collectable, so __del__ wouldn't be called in the first place.
>> That all seems too simple, though. Since we're talking about gc and 
>> that's never simple, there has to be something wrong with the idea :)
> Unfortunately you're right... this is all too simple. The existing
> mechanism doesn't have a problem with __del__ methods that do not
> participate in loops. For those that DO participate in loops I
> think it's perfectly plausible for your __del__ to receive a reference
> to the actual object being finalized.

Nope. If the argument to __del__ has a strong reference to the object, that 
object simply won't get finalized at all because it's not in an unreachable 
cycle. sys.finalizers would act as a global root for all objects reachable 
from finalizers (with those refcounts only be decremented when the callback 
removes the weakref object from the finalizer set).

> Another problem (but less important as it's trivially fixable) is that
> you're storing away the values that the object had when it was created,
> perhaps missing out on things that got added or initialized later.

The default fallback doesn't do that - it stores a reference to the instance 
dictionary of the object so it sees later modifications and additions.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-3000 mailing list