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
--
http://mail.python.org/mailman/listinfo/python-list
