On 10/8/07, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Mon, 08 Oct 2007 04:06:55 +0000, Michele Simionato wrote: > > > > Hmmm... I'm not sure I understand how a with statement is meant to > > > replace class.__del__ in practice. It seems to me that the two things > > > have different uses. with is useful when you create an object, do > > > something with it, dispose of it in an orderly fashion, and then > > > continue. How does that help when you create an unknown number of > > > long-lasting objects where you can't predict how and when they will be > > > disposed of? > > [snip] > > >> Now, I don't think the above is feasible. What am I missing? > > > > Rename your __del__ to close and call it explicitely: > > > > p.close() > > alist[3].close() > > alist[853].close() > > alist[701].close() > > Well, that utterly sucks. If I wanted to call finalizers explicitly, I'd > be writing in C. > > You say that using __del__ leads to hard-to-debug "bombs in my code > waiting to explode at some unknown moment". Maybe so -- but so does > explicitly managing resources by hand in the way you suggest, and quite > frankly, I suspect I'd have a hell of a lot fewer bugs by relying on > __del__ and the garbage collector than I would from managing resources > manually in a big project. >
The point that is being made is that "relying on __del__" is stupid, because __del__ isn't reliable. It's akin to a Java finalizer - there is no guarantee that it will be called at all. So you can use __del__, and have to be continually aware of the dangers of circular references and refcounting, or you use explicit finalizers, or you can use context managers. If you have arbitrary numbers of long-lived, potentially self-referential objects that you can't control in any other way, you're screwed - you're going to *have* to have a manual destruction somewhere. -- http://mail.python.org/mailman/listinfo/python-list
