Q.Why is it advised to close a file after we are done with the read and write operations? What will happen if we do not close it? Will some error message be flashed?

Concept: Resource Management — File Handling

This is a plain theory question about file resource management in Python.

Why closing a file is advised

When you open a file using open(), the operating system allocates a file descriptor — a low-level handle that tracks the file's position, access mode, and buffered data. Python's file object holds this descriptor in memory. Closing the file with close() releases that descriptor back to the OS.

The main reasons are:

• Buffer flushing: Writes to a file are often buffered in memory for efficiency. close() forces any remaining buffered data to be written to disk. Without it, you can lose data if the program crashes or ends abnormally.
• Resource exhaustion: Operating systems have a limit on how many files a process can open simultaneously (typically 1024 on Linux, 512 on older Windows). Leaving files open consumes these descriptors. If you open many files in a loop without closing them, you'll eventually hit the limit and get an OSError: [Errno 24] Too many open files.
• File locking: On some systems, an open file may be locked, preventing other processes from reading or writing it. Closing releases the lock.

What happens if you do not close it?

No error message is flashed immediately. Python does not automatically raise an exception when you forget to close a file. The file remains open until one of these happens:

1. The program ends — Python's garbage collector eventually calls __del__ on the file object, which closes it. But this is not guaranteed to happen promptly or at all in CPython's reference-counting model if there are circular references.
2. The file object goes out of scope and is garbage-collected — again, timing is unpredictable.
3. You hit the OS file-descriptor limit — then you get an error. …

The Idea: Resource Management

Every time you open a file in Python, the operating system allocates a file descriptor — a small integer handle that the OS uses to track the open file. Your program gets a limited number of these descriptors (typically 1024 per process on Linux, 512 on older Windows). More importantly, the file object holds a buffer in memory: data you write goes into this buffer first, and only gets physically written to disk when the buffer fills up or when you explicitly flush or close the file.

The close() method does two critical things:

1. Flushes the write buffer — forces any remaining data from memory to disk.
2. Releases the file descriptor back to the OS — so another file can be opened.

If you never close, neither of these happens reliably.

What Actually Happens If You Don't Close?

No, Python does not flash an error message. The program runs perfectly — until it doesn't. Here is what goes wrong:

Data loss. If your program writes to a file and then crashes or exits normally without closing, the last chunk of data sitting in the buffer may never reach the disk. The file on disk will be incomplete or even empty. This is the most dangerous consequence because it is silent — no error, no warning, just missing data.

Resource leak. Every open file descriptor stays occupied. If your program opens many files in a loop without closing them, you will eventually hit the OS limit and get an error like OSError: [Errno 24] Too many open files. This is rare in small scripts but common in long-running server processes.

Locked files (Windows). On Windows, an open file handle can prevent other programs (or even the same program later) from opening the file. You might get a "file in use" error when you try to read the file again.

Garbage collection is not guaranteed. Python's garbage collector will eventually close the file when the file object goes out of scope and gets destroyed. But "eventually" is unpredictable — it might be seconds, minutes, or never in a long-running program. Relying on it is bad practice.

The Right Way: The with Statement

Python provides a clean solution that eliminates the problem entirely: