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 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. (If nothing else, a call to os._exit() will
always bypass normal shutdown.) In Jython, for
example, there is no reference counting the way CPython
does it, so __del__ methods are called only when the
object is garbage collected. When does that happen?
There's no guarantee: if you haven't explicitly closed
the file, it might not get closed until the interpreter
is shutting down (if then).
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.
-Peter
--
http://mail.python.org/mailman/listinfo/python-list
