Python Reading & Writing Files

Every program that outlives a single run needs a way to persist data outside its own memory: a machine-learning script that loads a training dataset from disk, a web scraper that writes results to a CSV, a CLI tool that reads a config file on startup. File I/O — Input/Output — is the set of operations Python gives you for exactly this: opening a connection to a file on disk, reading bytes or text out of it, and writing new data back in.

Unlike a variable, which disappears the moment your script ends, a file on disk survives between runs. That durability is exactly why it's the default choice for logs, datasets, saved configuration, and any output a user or another program needs to consume later — but it also means file operations can fail in ways in-memory operations can't: a path might not exist, a disk might run out of space, or another process might be holding the file open.

Python represents an open file as a file object, returned by the built-in open() function. That object exposes methods like .read(), .write(), and .readline(), and it internally tracks a 'cursor' position — where the next read or write will happen — which is why reading a file twice in a row without resetting the cursor returns an empty string the second time.

The traditional way to work with a file uses open('data.txt', 'r'), which returns a file object connected to that path in read ('r') mode. Calling .read() on it loads the entire contents into memory as one string, and print(content) displays it. The second argument to open() — the mode — controls what's allowed: 'r' for reading, 'w' for writing (which erases existing content first), 'a' for appending, and 'b' combined with any of those for binary data like images.

The critical step easy to forget is file.close(). Every open file consumes an operating-system resource called a file descriptor, and most systems allow only a limited number of these to be open at once per process. If you never close files, long-running programs — the exact kind that processes many files, like a data pipeline — will eventually hit 'too many open files' errors, and on Windows an unclosed file can even stay locked against other programs trying to access it.

The deeper problem is that close() has to actually run to have any effect, and if an exception is raised between open() and close() — say, .read() fails partway through — the close() call is skipped entirely, leaking the file handle. Manually calling close() after every open() is exactly the pattern Python's context managers exist to make unnecessary.

The with statement is the Pythonic fix for the close() problem: with open('data.txt', 'r') as file: opens the file, binds it to file for the duration of the indented block, and guarantees .close() runs automatically when the block exits — whether it exits normally or because an exception was raised partway through. This is Python's context manager protocol at work: open() returns an object with __enter__ and __exit__ methods, and with calls them for you at the right moments. There is no scenario where code inside a with open(...) block can leak the file handle, which is why style guides and linters treat a bare open()/close() pair as a code smell.

Writing introduces a second decision on top of context managers: which mode to open in. 'w' mode truncates the file to zero bytes the instant it's opened, even before you write anything — call open('logs.txt', 'w') on a file you meant to append to, and its previous contents are already gone. 'a' mode instead seeks to the end of the file and only ever adds new bytes after existing content, which is why log files, audit trails, and anything else that accumulates over multiple runs should almost always use 'a', not 'w'.

A final detail that trips people up on non-English text or Windows machines: open() uses a platform-dependent default text encoding unless you pass one explicitly. Writing UTF-8 characters like accented letters or emoji without encoding='utf-8' can raise a UnicodeEncodeError on one machine while working fine on another — always pass encoding='utf-8' explicitly when opening text files to keep behavior consistent across platforms.

AI Models run on Data. To train an AI, parse logs, or save configurations, you must master reading and writing files in Python.

The traditional way uses 'open()'. You specify the filename and mode. 'r' stands for read. Don't forget to close() it!

When executed, Python loads the text from the disk into your variable. But remembering to close() files is error-prone.

Checkpoint: What happens if you open a file without specifying a mode (e.g., open('data.txt'))?

• →It throws an Error
• →It defaults to Read ('r')

The 'with' statement is the Pythonic standard. It's a Context Manager that automatically closes the file for you!

Using 'with' guarantees the file is closed even if your code crashes inside the block. Always use it!

To write data, use 'w' mode. Warning: 'w' overwrites everything! Use 'a' to append to the end of the file.

Checkpoint: Which mode should you use to add data to the end of a file WITHOUT deleting existing content?

• →'w' (Write)
• →'a' (Append)

Files are the lifeblood of data persistence. Start building your data pipelines today!

Read and Write a Real File. Finish write_and_read(): the with statement guarantees the file closes automatically.