Python vs Java garbage collection?

[holger krekel]

Beni Cherniavsky wrote:
> On 2003-01-06, holger krekel wrote:
> 
> > Beni Cherniavsky wrote:
> > > On 2002-12-28, Stuart D. Gathman wrote:
> > >
> > > > 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)
> >
> > why is this better than the traditional e.g.
> >
> > lock.acquire()
> > try:
> >   do_critical_work()
> > finally:
> >   lock.release()
> >
> Err, emmm, aah, Good Question. :-)
> 
> More seriously, it allows one to always call the destructor __del__
> without knowing in advance whether the user will be happy with relying on
> automatic finalization or will destroy it excplicitly.  In particular,
> suppose I write a module and it relies on __del__; now somebody wants to
> use it in Jython and/or in some context I didn't envision that requires
> explicit finalization at some predictable time.  Currently, he has no way
> short of changin my module and redesigning the interface.  I don't think
> there is currently a good way to "fry" an object before its time from pure
> Python, so calling __del__ manually is problematic.

Right, this is problematic. 

Regarding your module, If you have something like:

    def f():
        data = open(source).read()

then it is hard to finalize the file from the outside.
We don't even have a name to refer to.  
 
> Also, since I never saw a resources that can be destroyed in more than one
> way <wink>, it makes some sense to have a single name agreed name for it.
> Sometimes, it could allow writing generic code that releases a resource
> without knowing what it is exactly.  For example, in a related thread some
> time ago I proposed that the for loop should finalize the iterator (with
> finally-like guarantee.

Hmmm.  Care to give a concrete example? 

> In CPython, it already happens (__del__ is
> called) and in Jython this would need to be coded.  It can't quite work
> that way because people sometimes give pre-existing iterators to for,
> expecting them to remain alive.  Still, it shows the idea: an API that
> creates user objects without exposing it, has known lifetime for the
> object but gives the user no way to finilize explicitly, so it makes very
> much sense for the API to guarantee this finilization.  Currently you
> cannot implement such a guarantee under Jython; with the added builtin,
> you can.

I am not so sure how (and why) something like a 'finalize' builtin could be 
made to work.  I don't have the situation often where i don't know how
to finalize a resource.  

    holger