does python have useless destructors?

[Donn Cave]

In article <slrnccetd9.gag.msoulier at tigger.digitaltorque.ca>,
 "Michael P. Soulier" <msoulier at digitaltorque.ca._nospam> wrote:

> I recently had a friend tell me that because the Python spec does not
> guarantee that an object will necessary be destroyed when all references
> to it are gone, that desctructors in Python are not reliably called, and
> thus useless. As I found it difficult to believe that Python would
> include destructors for apparently no reason, I thought I should ask for
> clarification here.
> 
> Can anyone say yay or nay on this issue? 
> 
> I believe his comments stem from a couple of references. 
> 
> http://docs.python.org/ref/customization.html#l2h-174
> http://docs.python.org/ref/objects.html#l2h-18
> 
> Specifically, this paragraph in the second link:
> 
>     Some objects contain references to ``external'' resources such as
>     open files or windows. It is understood that these resources are
>     freed when the object is garbage-collected, but since garbage
>     collection is not guaranteed to happen, such objects also provide an
>     explicit way to release the external resource, usually a close()
>     method. Programs are strongly recommended to explicitly close such
>     objects. The `try...finally' statement provides a convenient way to
>     do this.
> 
> So putting a close of some external resource in a destructor would be a
> bad idea, apparently. As this is the kind of thing I typically use
> destructors in OO programming for, I found this quite surprising.

To answer your question, no, I don't think anyone can say
yea or nay on this issue.

There are two not-guaranteed issues with finalization.

-  Reference cycles can prevent immediate finalization.
   If an object holds a reference to itself, however
   indirectly, it won't be deleted automatically and has
   to be recovered through garbage collection, and garbage
   collection won't delete instances with a __del__ method,
   among other things.

-  The Java implementation can't implement immediate
   finalization because Java doesn't have it.  In general,
   Python's storage model isn't fully defined and its semantics
   may vary according to the host language.

On the other hand, while we can't completely resolve this
problem, I think the text you quota above errs in trying
to paint it as a non-problem.  try..finally is certainly
not a convenient substitute for guaranteed finalization.
The immediate finalization normally supported in Python
is a very powerful, elegant programming feature.  For just
the same reasons that automatic control of memory allocation
is powerful and elegant -- memory is one of the resources
your objects use.

So yes, you can depend on immediate finalization in many
common situations, but you have to accept the liability of
a dependence on reference non-circularity and on the C Python.

   Donn Cave, donn at u.washington.edu