Re: [Python-Dev] Removing __del__
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
Re: [Python-Dev] Removing __del__
Adding pydev back in, since these seem like reasonable questions to me :) Jim Jewett wrote: On 9/20/06, Nick Coghlan [EMAIL PROTECTED] 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 (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__. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
Re: [Python-Dev] Removing __del__
Nick Coghlan wrote: Adding pydev back in, since these seem like reasonable questions to me :) D'oh, that should have been python-3000 not python-dev :( Sorry for the noise, folks. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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
