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.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
