On Thu, 2004-12-09 at 10:33 -0500, Peter Hansen wrote:
> John Marshall wrote:
> > It seems to me that a file.__del__() _should_
> > call a file.close() to make sure that the file
> > is closed as a clean up procedure before
> > releasing the object.
>
> I believe it does, but I tried your experiment
> with subclassing file and didn't ever see a
> call to close, so I can only assume that the
> built-in __del__() is actually just calling the
> builtin close() and bypassing my overridden close(),
> although there could also be some other magic about
> how files behave that explains this.
>
I took a look at the filemodule.c code and in the
file_dealloc() which is registered as the destructor,
a close() is done on the file as your surmised.
In fact, the file_dealloc() does not even call
the file_close() but simply does an OS close().
> > I don't see why this is so only for small scripts. As
> > I question above, why doesn't the file object clean up
> > after itself as a guaranteed course of action?
>
> The issue is that although __del__ is calling
> close, there is no guarantee in Python about when
> __del__ is run, nor in fact that it will ever be
> run.
>
> In CPython, you at least (currently) have sort of a
> guarantee that the file will be closed when the object
> is destroyed, which because of reference counting will
> happen as soon as you "del file" or rebind the name
> to another object, or whatever.
>
> So in CPython, it is working properly (and you shouldn't
> run out of file descriptors unless you are into
> complicated code where the file objects are being kept
> in cyclical data structures that cannot be reclaimed
> through simple reference counting) but I cannot explain
> why we don't see a subclass's close() method get called
> when __del__ does, as it must, get called.
Thanks for the explanation. After reading some of
the comp.lang.python stuff it seems that an improvement
to the Python FAQ would be worthwhile (unless I've
missed something else in it). The FAQ (1.6.11) says,
The del statement does not necessarily call
__del__ -- it simply decrements the object's
reference count, and if this reaches zero __del__
is called.
This really does communicate that Python (not
unambiguously CPython only, as of 2004-12-09) will
call __del__ when refcount == 0.
It seems that if one cannot expect __del__ to be
called when nothing references it (using any GC
approach) then its only use is to free
memory/objects not to release other resources such
as file descriptors, socket descriptors, etc.
Thus the recommendation to explicitly do a
file.close() after reading.
Thanks,
John
--
http://mail.python.org/mailman/listinfo/python-list
