Questions about file object and close()

[John Marshall]

On Thu, 2004-12-09 at 08:41 -0500, Peter Hansen wrote: 
> John Marshall wrote:
> > Hi,
> > 
> > Does anyone see a problem with doing:
> >     data = file("tata").read()
> > 
> > Each time this is done, I see a new file
> > descriptor allocated (Linux) but not
> > released.
> > 
> > 1) Will there ever be a point where I
> >    will have a problem with file
> >    descriptors because the garbage
> >    collector has _not_ yet collected the
> >    file objects?
> 
> Should be easy to check.  Write a loop which
> does that many times.  There are a finite
> number of file descriptors available, so if
> it's going to fail, it will fail fairly
> quickly.
> 

I did do this and it did not fail. My concern
was since the close() is not done explicitly
by me, and does not seem to be called in
a file.__del__() or otherwise, I was not
sure. I want to be sure! Given your comment
below about the CPython implementation, there
is no guarantee which seems unreasonable for
such an operation.

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 cannot see why this
would not be the prescribed behavior and thus
my question. Isn't that what __del__
(destructors) are supposed to handle--cleaning
up?

> > 3) There is no file.__del__() as far as I
> >    can tell at the Python level. Are files
> >    opened by the calls above properly
> >    closed when the objects are destroyed
> >    and collected?
> 
> Yes, but you can only count on this happening
> in the CPython implementation.  Nevertheless,
> it's still widely considered more than just good style
> to explicitly close your files within a finally
> clause, even in CPython where technically you don't
> have to in most cases:
> 
> f = file("tata")
> try:
>      data = f.read()
> finally:
>      f.close()
> 
> The above is quite robust and should be your model
> for all file access, at least until you're much more
> experienced with Python.

How would more experience change this? Assuming I
am catching any exceptions I am interested in, why
wouldn't the following be just as good?
try:
    data = file("tata").read()
except:
    ...


> One should use the open().read() idiom only in small
> utility scripts and other such short-running applications.

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?

Of course, I could implement my own file object to
guarantee the clean up and be on my way. But I am
still surprised at what I am seeing.

Thanks,
John