"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > If they don't get GC'd, then "when they are GC'd" is never. The point > is that the standard library _does_ close files and take other > program-visible actions in __del__ methods; I'm unclear on if you think > that doing so is actually sloppy practice
I don't know if I'd say "sloppy"; it's certainly messy and can lead to complex bugs, but there are pragmatic reasons for wanting to do it in some situations and it can be used to good purpose if you're careful. But I think people sometimes expect too much from it, as Steve Holden indicated. It should not be compared with C++ destructors, since C++ deallocation is explicit. I'm not sure what other languages with actual GC support anything like it. I implemented it in Lisp once but found it disconcerting since some of the stuff removed by GC in the system I was working on were no-longer-referenced graphics objects on the screen, which would thereby wink out of existence at surprising times. I concluded that the application should keep track of stuff like that instead of tossing them into the air for the GC to clean up. > I originally thought that was what you meant when you said that "GC is > supposed to make it look like every object stays around forever, and > any finalizer that causes an explicit internal state change in an > extant object (like closing a file or socket) is not in the GC spirit > to begin with." but going back and reading it I'm not sure. GC is supposed to just release resources that are no longer referenced (since you can't tell whether they're still around, you can act as if they are always stay around). For files, maybe closing them is ok--the file abstraction mimics synchronous i/o and in the idealized version, closing them is a do-nothing and the closure is undetectable. For sockets (which are supposed to send particular messages over the wire when the socket shuts down) it's less appealing. -- http://mail.python.org/mailman/listinfo/python-list