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

Reply via email to