Queue cleanup

[Paul Rubin]

John Nagle <nagle at animats.com> writes:
>     I've argued for an approach in which only synchronized or immutable
> objects can be shared between threads.  Then, only synchronized objects
> have refcounts.  See
> "http://www.animats.com/papers/languages/pythonconcurrency.html"

I'm going to have to read this carefully, but my first reaction is that
doing it right would take substantial changes to the language, to the
point where it wouldn't really be Python any more.  

More generally, if you want to program in Erlang, why not use Erlang for
that?

> I can't think of a time when I've really had to use a finalizer for
> something with dynamic extent.  They've always seemed like a code
> smell to me.

   The problem appears when you have an object that owns something, like
a window or a database connection.  "With" is single-level.

But expecting such an object to be gc'd seems like a code smell in its
own right.  I once implemented something like that in a Lisp system, and
it was just disconcerting as hell to see windows on the screen blink out
of existence unpredictably.  The issue is maybe your function returns
and you expect the window to vanish, but something somewhere has saved
another temporary reference to it so it doesn't go away til later.  If
you want something with external semantics (like a window or file
handle) to be released at a particular time, the program should do that
explicitly.  Don't use a finalizer that you expect storage reclamation
to invoke.  There is just too little control in a Python program over
the creation of references.