Why Should I Close Files in Python

Why should I close files in Python?

For the most part, not closing files is a bad idea, for the following reasons:

1. It puts your program in the garbage collectors hands - though the file in theory will be auto closed, it may not be closed. Python 3 and Cpython generally do a pretty good job at garbage collecting, but not always, and other variants generally suck at it.

2. It can slow down your program. Too many things open, and thus more used space in the RAM, will impact performance.

3. For the most part, many changes to files in python do not go into effect until after the file is closed, so if your script edits, leaves open, and reads a file, it won't see the edits.

4. You could, theoretically, run in to limits of how many files you can have open.

5. As @sai stated below, Windows treats open files as locked, so legit things like AV scanners or other python scripts can't read the file.

6. It is sloppy programming (then again, I'm not exactly the best at remembering to close files myself!)

Why should I close file

By not closing files you are possibly wasting system resources. Also, other processes that want to access the file after your code was executed might not be able to do so due to still being opened by your code.

Is it necessary to close files after reading (only) in any programming language?

In general, you should always close a file after you are done using it.

Reason number 1: There are not unlimited available File Descriptors
(or in windows, the conceptually similar HANDLES).
Every time you access a file ressource, even for reading, you are reducing the number of handles (or FD's) available to other processes.
every time you close a handle, you release it and makes it available for other processes.

Now consider the consequences of a loop that opens a file, reads it, but doesn't close it...

http://en.wikipedia.org/wiki/File_descriptor

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364225%28v=vs.85%29.aspx

Reason number 2: If you are doing anything else than reading a file, there are problems with race conditions, if multiple processes or threads accesses the same file..
To avoid this, you may find file locks in place.
http://en.wikipedia.org/wiki/File_locking

if you are reading a file, and not closing it afterward, other applications, that could try to obtain a file lock are denied access.

oh - and the file can't be deleted by anyone that doesn't have rights to kill your process..

Reason number 3: There is absolutely no reason to leave a file unclosed. In any language, which is why Python helps the lazy programmers, and automatically closes a handle that drops out of scope, in case the programmer forgot.

Do we need to close a file using open in python?

The python equivalent is in_file.close(). While it's always good practice to close any files you open, python is a little more forgiving - it will automatically close any open file handlers when your function returns (or when your script finishes, if you open a file outside a function).

On the other hand, if you like using python's nested indentation scopes, then you might consider doing this (valid as of python 2.7):

with open('1234.bin', 'rb') as infile:
    x = np.fromfile(infile, dtype='int32')
# other stuff to do outside of the file opening scope

EDIT: As @ShadowRanger pointed out CPython will automatically close your file handlers at function-return/end-of-script. Other versions of python will also do this, though not in a predictable way/time

about close a file in Python

Python will, in general, garbage collect objects no longer in use and no longer being referenced. This means it's entirely possible that open file objects, that match the garbage collector's filters, will get cleaned up and probably closed. However; you should not rely on this, and instead use:

with open(..):

Example (Also best practice):

with open("file.txt", "r") as f:
    # do something with f

NB: If you don't close the file and leave "open file descriptors" around on your system, you will eventually start hitting resource limits on your system; specifically "ulimit". You will eventually start to see OS errors related to "too many open files". (Assuming Linux here, but other OS(es) will have similar behaviour).

Important: It's also a good practice to close any open files you've written too, so that data you have written is properly flushed. This helps to ensure data integrity, and not have files unexpectedly contain corrupted data because of an application crash.

It's worth noting that the above important note is the cause of many issues with where you write to a file; read it back; discover it's empty; but then close your python program; read it in a text editor and realize it's not empty.

Demo: A good example of the kind of resource limits and errors you might hit if you don't ensure you close open file(s):

$ python
Python 2.7.6 (default, Mar 22 2014, 22:59:56) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> xs = [open("/dev/null", "r") for _ in xrange(100000)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 24] Too many open files: '/dev/null'

Should I close a file with file.close() when there is a FileNotFoundError exception?

A simpler method of checking if a file exists:

import os

if not os.path.exists(sys.argv[1]):
    print(f"{sys.argv[1]} file not found.")

But to answer your question, the ```file.close()`` happens only when the file exists and you successfully open the file. Not when the exception occurs.

Edit:
As pointed out by @ekhumoro, the above has a race condition (when other processes access that file). If no other process accesses that file, then the above code works.

Solution is as @ekhumoro pointed out is to use your original try/except method.

If you're opening a file using the 'with' statement, do you still need to close the file object?

The answer to your immediate question is "No". The with block ensures that the file will be closed when control leaves the block, for whatever reason that happens, including exceptions (well, excluding someone yanking the power cord to your computer and some other rare events).

So it's good practice to use a with block.

Now arguably, having opened a file only for reading and then failing to close it is not that much of a problem. When garbage collection comes around (whenever that may be), that file will be closed, too, if there are no references to it anymore; at the latest that will happen when your program exits. In fact, several code samples in the official docs neglect closing a file that has been opened only for read access. When writing a file or when using the "read plus" mode like in your example, you definitely need to close the file. There are many questions her on SO dealing with incomplete/corrupted files because of a failure to close them properly.

---

Related Topics