Paul Rubin wrote: > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > > > We had that debate already (PEP 343). Yes, there is some sloppy > > > current practice by CPython users that relies on the GC to close the > > > db conn. > > > > This point is unrelated to with or ref-counting. Even the standard > > library will close file objects when they are GC'd. > > I don't think so. AFAIK, there is no such thing as "when they are > GC'd" in the language spec.
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 (as opposed to users of the standard library relying on the GC running in some deterministic manner or even at all, which you clearly do think is sloppy practice). 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. -- http://mail.python.org/mailman/listinfo/python-list
