Python vs Java garbage collection?

[Beni Cherniavsky]

On 2002-12-28, Stuart D. Gathman wrote:

> On Thu, 26 Dec 2002 15:28:35 -0500, Antonio Cuni wrote:
>
> > I'd like if python had a feature comparable to C++'s deterministic
> > destructors; something like the following (invented syntax):
> >
> > def foo():
> >   auto mymutex = acquire_mutex()
> >   auto myfile = open(filename, 'w')
> >   auto mysocket = open_socket()
> >   do_stuff
> >
> > I presume it's not easy to assure that "auto" variables can be destroyed
> > at the end of the function: e.g., what if objects bound to auto
> > variables have refcount > 1 ?
>
I was lately thinking along similar lines.  For Jython and for any
resource release, one must indicate explicitly when to destroy the object.
Whatever syntax you use, you still define a predictable place where the
object is destroyed.  No way around it.  So I don't think one should be
troubled by remaining references to the object - if the programmer chose
to end the object's life, he should realise that that's what he's doing.

> 1) This feature should not reclaim memory, only call __del__().If
> references were still live, the effect would be the same as calling
> __del__() on a live object.
>
> 2) __del__() would get called again when memory is actually reclaimed.
> Therefore, your feature would be much safer if it called another special
> function - say close() or dispose() at the end of the block.
>
I think this is a technical question: is it possible in CPython and Jython
to mutate an existing object's class, to mark it as dead?  If yes, then a
facility to explicitly force a __del__ if any (and fry the object so it
can't be used any more) would be a solution for writing portable code:

x = acquire()
try:
    do_something(x)
finally:
    finalize(x)

This would manualy guarantee a timely __del__.  If frying the object to
prevent the double __del__ is a problem, __del__ must be given up for
such cases and a new attribute should be agreed upon.

-- 
Beni Cherniavsky <cben at tx.technion.ac.il>