Python vs Java garbage collection?

[Beni Cherniavsky]

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.

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.  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.

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