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