threading support in python

[Paul Rubin]

"sjdevnull at yahoo.com" <sjdevnull at yahoo.com> 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.