[Python-Dev] Removing __del__

Giovanni Bajo rasky at develer.com
Sun Sep 24 01:29:27 CEST 2006


Marcin 'Qrczak' Kowalczyk wrote:

>> 1) There's a way to destruct the handle BEFORE __del__ is called,
>> which would require killing the weakref / deregistering the
>> finalization hook.
>
> Weakrefs should have a method which runs their callback and
> unregisters them.
>
>> 2) The objects required in the destructor can be mutated / changed
>> during the lifetime of the instance. For instance, a class that
>> wraps Win32 FindFirstFirst/FindFirstNext and support transparent
>> directory recursion needs something similar.
>
> Listing files with transparent directory recursion can be implemented
> in terms of listing files of a given directory, such that a finalizer
> is only used with the low level object.
>
>> Another example is a class which creates named temporary files
>> and needs to remove them on finalization. It might need to create
>> several different temporary files (say, self.handle is the filename
>> in that case)[1], so the filename needed in the destructor changes
>> during the lifetime of the instance.
>
> Again: move the finalizer to a single temporary file object, and refer
> to such object instead of a raw handle.

Yes, I know Python is turing-complete even without __del__, but that is not my
point. The fact that we can enhance weakrefs and find a very complicated way to
solve problems which __del__ solves right now easily does not make things
different. People are still propsing to drop a feature which is perceived as
"easy" by users, and replace it with a complicated set of workarounds, which
are prone to mistakes, more verbose, hard to learn and to maintain.

I'm totally in favor of the general idea of dropping rarely used features (like
__var in the other thread). I just can't see how dropping __del__ makes things
easier, while it surely makes life a lot harder for the legitimate users of it.

Giovanni Bajo



More information about the Python-Dev mailing list