File not closed on exception

Bruno Desthuilliers bruno.42.desthuilliers at websiteburo.invalid
Tue Oct 20 10:00:58 EDT 2009


arve.knudsen at gmail.com a écrit :
> On Oct 19, 4:14 pm, Grant Edwards <inva... at invalid.invalid> wrote:
>> On 2009-10-19, arve.knud... at gmail.com <arve.knud... at gmail.com> wrote:
>>
>>> I thought that file objects were supposed to be
>>> garbage-collected and automatically closed once they go out of
>>> scope,
>> At some point after they go out of scope, they will be.
>> Eventually.  Exactly when is an implementation detail.
>>
>>> at least that's what I've been told by more merited Python
>>> programmers. I'm also quite sure that this is quite a common
>>> assumption in various programs,

AFAICT, the file descriptor associated to the file object will be freed 
when the CPython process will finish - which implies you're using the 
CPython interpreter. This doesn't mean the file is garanteed to be 
closed _at the point where you're trying to os.remove() it_. And as I 
said, this is a CPython implementation detail - not a language 
specification. Jython or IronPython (or any other implementation) may 
not work that way.

>> If your program relies on the assumption that some particular
>> object will be garbage-collected between points A and B, then
>> that's a bug in your program.  If you depend on the fact that
>> some object has been delted, then "del" it.  If you depend on
>> the fact that a file is closed, then close it.
> 
> Personally I am against that assumption, and prefer a utility function
> which reads the file and automatically closes it in a "finally" block
> (in lieu of the "with" keyword).

What's your problem with the with ???

But anyway : explicitely releasing resources such as files, network 
connections etc is of course the RightThing(tm), except eventually in 
one-shot throwaway scripts.

> However, when providing a patch for a
> high-profile opensource Python project I was scolded for going to such
> lengths, as the prescribed style was to just open files and let them
> be closed implicitly.

Err... Care to name the project ? I hope it's not one I ever advertized :(




More information about the Python-list mailing list