John Nagle <na...@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. -- http://mail.python.org/mailman/listinfo/python-list
