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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
