Answer.

with open(...) as f: is the standard way to work with files using a context manager. With this approach, Python guarantees that the file will be automatically closed upon exiting the with block, even if an exception occurs. This prevents file descriptor leaks and file locks.

Inside the block, you can work with the file using the object's methods (f.read(), f.write(), etc.). After exiting the block (even in case of an error), the f.close() method is called.

Example:

with open('data.txt', 'w') as f:
    f.write('Hello!')
# The file is already closed here

Trick question.

Common question:

Can you be sure that a file opened with open will close immediately after exiting the with block, even if an exception occurs in the middle of the block?

Answer: Yes, that is precisely what the context manager contract guarantees: regardless of exceptions, the __exit__ method is called upon exiting the block, which results in the file being closed. This is the main advantage compared to explicitly calling f.close().

Examples of real errors due to ignorance of the topic's subtleties.

---

Story

In a large project, logging was done through open('log.txt', 'a') and an explicit call to f.write(), but f.close() was forgotten. After a long operation, the process exhausted all OS file descriptors, and the service stopped working.

---

Story

In a monitoring system, files were constantly opened via open, and exceptions were not handled. When an error occurred, the file remained open, leading to locks when attempting to reopen from another process.

---

Story

A developer implemented reading a large file via open and immediately returned in the middle of the function without closing the file. As a result, several such operations led to file resource overflow, and the OS started blocking new openings.