[Python-3000] Removing __del__

Nick Coghlan ncoghlan at iinet.net.au
Thu Sep 21 12:26:18 CEST 2006

Second attempt, this time to the right list :)

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