Writing Files

Opening a text file for an intentional kind of write

Python's built-in open() returns a file object connected to a path. For ordinary text output, a clear pattern is with open("report.txt", "w", encoding="utf-8") as file: followed by an indented block. The path says where the output goes; the mode says what kind of access is requested; and the encoding says how Python converts text strings to bytes for storage. This lesson uses UTF-8 explicitly because Python's documentation notes that an unspecified text encoding is platform-dependent and recommends UTF-8 unless another encoding is known to be needed. An encoding is not decoration: it is the agreed mapping between characters in a Python string and stored bytes.

The mode changes the consequences of the operation. "w" opens a file for writing and truncates it if it already exists. In plain language, a successful w write begins with an empty file; it is suitable for a report whose complete current version should replace an old version. "a" opens for appending, so new output is written at the end. It suits a simple log where a new event should follow earlier events. Neither mode is universally safer. The correct choice follows the program's promise to its user. Before using w, decide whether replacement is really intended; before using a, decide whether retaining prior entries is really intended. Exclusive creation (x) and file-existence handling are useful adjacent concerns, but they are outside this focused lesson.

The context manager owns the closing boundary

A file is a resource with a lifecycle. A program opens it, uses it, and should close it. The with statement creates a context-managed block: Python binds the opened file object after as file, runs the block, and closes the file when the block is left, including when normal flow leaves it because the block finishes. That makes the intended lifetime visible in the code. It also avoids relying on a later, easily forgotten file.close() call. The official tutorial presents this pattern as good practice because the file is properly closed after its suite finishes.

Closing matters because buffered output may need to be finalized and because a program should release resources it no longer needs. The practical rule is simple: keep the write operations inside the with block and do not try to use the file object as an open writer after the block. A context manager does not decide what content belongs in a file or protect a program from choosing w accidentally. It handles the resource boundary; the programmer still chooses the path, mode, encoding, and strings deliberately.

This lesson is about producing output, not inspecting it afterward. Reading a file is covered separately. In real work, a program may later verify output through a read or test, but that is a distinct workflow. Likewise, detailed exception strategies belong with exceptions. Here, the dependable starting pattern is an explicit text encoding plus a short with block whose purpose is to write the planned content.

Writing strings, lines, and delimiters

file.write(text) accepts one string and returns the number of characters written. It does not automatically add a line break. Thus file.write("First line") followed by file.write("Second line") produces adjacent text unless the programmer includes a separator such as "\n". A newline is data in the string, not an invisible side effect of write. This detail is important for line-oriented formats and logs: a visual line in source code is not automatically a line in the output file.

file.writelines(lines) writes each string from an iterable of strings. Despite its name, it also does not add line separators. A useful call is file.writelines(["April\n", "May\n"]), where each supplied string already carries its own newline. If the supplied strings are ["April", "May"], the stored result is AprilMay. Use write when one constructed string is clearest; use writelines when the program already has a sequence of complete string fragments or line strings. Neither method turns arbitrary values into text automatically, so format numbers or other data into strings before passing them.

A good output design makes separators visible. For a small report, collecting strings with explicit \n characters can be more readable than scattering many write calls. For a log, a single write call that includes one message and one terminating newline is often enough. The point is not to prefer one method by habit. State the output structure first, then choose the method whose input naturally matches that structure. This lesson deliberately does not cover parsing the resulting text, binary files, or error recovery; those need separate decisions and examples.