Leaving files open degrades application performance and increases the risk of unexpected side effects. Using
open as a context manager will close it automatically for you.
Computers have finite resources, including limits on how many files can be simultaneously open. Therefore leaving files open consumes more finite file handles than necessary. Under extreme conditions this could exhaust the number of allowed open files causing an "
IOError: Too many open files" exception to be raised. Additionally, leaving files open consumes finite memory for longer than is necessary. Therefore for performance of the application it is preferable to closing file after finished with them.
Python's garbage collection will eventually close dangling unclosed files, but "eventually" should raise a red flag if the goal is to write predictable software. Indeed, Python3 and Cpython might implicitly close the file the instant they're no longer being used, while others might not for a long time. Under some conditions it might not happen at all. When pairing this problem with the zen of Python's Explicit is better than implicit, it's clear that it's better to not leave files open.
Python can also be fuzzy around exactly when file changes are committed to disk: the data may not be written to disk until the file is closed:
Windows (the Operating System) locks files opened by Python. This means leaving files open is not thread safe as one thread will lock the file preventing other threads from opening it - even if the other thread just wants to read from it.
If our GitHub code review bot spots this issue in your pull request it gives this advice:
Code Review Doctor will run this check by default. No configuration is needed but the check can be turned on/off using check code
no-unclosed-files in your pyproject.toml file.