threading support in python

[sjdevnull at yahoo.com]

Paul Rubin wrote:
> "sjdevnull at yahoo.com" <sjdevnull at yahoo.com> 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.