[Python-Dev] Removing __del__
ncoghlan at gmail.com
Thu Sep 21 12:22:27 CEST 2006
Adding pydev back in, since these seem like reasonable questions to me :)
Jim Jewett wrote:
> On 9/20/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> # Create a class with the same instance attributes
>> # as the original
>> class attr_holder(object):
>> finalizer_arg = attr_holder()
>> finalizer_arg.__dict__ = self.__dict__
> Does this really work?
It works for normal user-defined classes at least:
>>> class C1(object):
>>> class C2(object):
>>> a = C1()
>>> b = C2()
>>> b.__dict__ = a.__dict__
>>> a.x = 1
> (1) for classes with a dictproxy of some sort, you might get either a
> copy (which isn't updated)
Classes that change the way __dict__ is handled would probably need to define
their own __del_arg__.
> (2) for other classes, self might be added to the dict later
Yeah, that's the strongest argument I know of against having that default
fallback - it can easily lead to a strong reference from sys.finalizers into
an otherwise unreachable cycle. I believe it currently takes two __del__
methods to prevent a cycle from being collected, whereas in this set up it
would only take one.
OTOH, fixing it would be much easier than it is now (by setting __del_args__
to something that holds only the subset of attributes that require finalization).
> and of course, if it isn't added later, then it doesn't hvae the full
> power of current finalizers -- just the __close__ subset.
True, but most finalizers I've seen don't really *need* the full power of the
current __del__. They only need to get at a couple of their internal members
in order to explicitly release external resources.
And more sophisticated usage is still possible by assigning an appropriate
value to __del_arg__.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev