[Python-Dev] Removing __del__

Nick Coghlan 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):
>>                  pass
>>              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):
...     pass
 >>> class C2(object):
...     pass
 >>> a = C1()
 >>> b = C2()
 >>> b.__dict__ = a.__dict__
 >>> a.x = 1
 >>> b.x

> (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 mailing list