Reading & Writing Files

To work with a file you first open it. Python's open() gives you a file object, and the modern, safe way to use it is inside a with block, which guarantees the file is closed again the moment you are done - even if something goes wrong midway:

with open("rooms.txt") as f:
    text = f.read()

print(text)

That small with line is doing real work. Opening a file reserves a resource from the operating system, and leaving files open causes subtle bugs - lost data, locked files, hitting limits. The with statement (a context manager) hands you the file as f, lets you work inside the indented block, and closes it automatically at the end. You could call f.close() yourself, but people forget, and forgetting bites. The habit to build from day one is simple: always open files with `with`. Everything else in this lesson happens inside that block - it is the frame around every file operation you will write.

It is worth being clear about what open() actually gives you, because the mental model prevents a lot of confusion. It does not read the file or load its contents into a variable; it returns a file object - a live connection to the file that you then send instructions through, like .read() or .write(). Think of it as opening a document rather than photocopying it: you now have it open in front of you and can act on it, but you have not yet taken anything out. That connection is a real operating-system resource, which is exactly why closing matters and why with exists. One more early note: open() takes a second argument, the mode, which says whether you intend to read, write or append. Leave it off and you get read mode by default - safe, because reading never changes a file. We will use the writing modes in a moment, but every file operation, read or write, begins with this same open() inside a with.

Once a file is open for reading you have choices about how much to pull in. Three patterns cover nearly everything:

with open("rooms.txt") as f:
    whole = f.read()            # everything as one string

with open("rooms.txt") as f:
    lines = f.readlines()       # a list, one string per line

with open("rooms.txt") as f:
    for line in f:              # one line at a time - memory-friendly
        print(line.strip())     # strip() removes the trailing newline

read() gives you the entire contents as a single string - fine for small files. readlines() gives a list where each item is one line. Looping directly over the file, for line in f, reads one line at a time without loading the whole file into memory, which matters for large exports. Notice line.strip(): text files store an invisible newline character at the end of each line, and strip() cleans it (and stray spaces) off. This is exactly the kind of small, real detail that trips beginners - the data looks right but has hidden \n characters. Reading files is where your loops and strings from earlier modules finally meet real project data.

Which pattern to choose comes down to size and intent. For a small settings file or a short list, read() is simplest - grab the lot and work with it. When you want to process a file record by record, looping directly over the file object (for line in f) is both the most readable and the most memory-efficient choice, because Python hands you one line at a time instead of loading a possibly huge export all at once. That efficiency is not academic: a BIM or point-cloud export can be hundreds of megabytes, and reading it line by line is the difference between a script that runs and one that exhausts your machine's memory. A common shape you will write again and again is to loop the lines, strip() each, skip blanks or a header row, and do something with the rest - a pattern that leads directly into reading real schedules in the next lesson. Everything you learned about strings - split(), slicing, .startswith() - now has real text to work on.

Writing is the mirror image, but you must say how you want to open the file - the mode. The default is "r" for reading; "w" opens for writing and overwrites the file, while "a" appends to the end:

rooms = ["living 18.0", "kitchen 12.0", "bedroom 14.0"]

with open("schedule.txt", "w") as f:
    for room in rooms:
        f.write(room + "\n")     # you add the newline yourself

with open("schedule.txt", "a") as f:
    f.write("study 9.0\n")       # added to the end, nothing lost

Two things catch everyone at first. First, "w" is destructive - it empties the file before writing, so a script pointed at the wrong filename can wipe real work; reach for "a" when you mean to add. Second, write() does not add line breaks for you the way print() does - if you want each room on its own line you append "\n" yourself, as above. Get those two habits right and writing files is genuinely easy. From here your scripts can produce real artefacts - a schedule, a report, a cleaned data file - that other people and other programs can open.

Because "w" is destructive, it is worth adopting one safety habit early: when a script overwrites data you care about, write to a new filename first, open the result, confirm it is right, and only then replace the original by hand. A wrong path or a stray "w" cannot then erase work you cannot recover. For building up a file across several runs - a log of what a batch script processed, say - "a" is exactly right, since each run adds to the end without disturbing what came before. And if you are writing many lines at once, you do not have to call write() repeatedly; f.writelines(list_of_strings) writes them in one go (though, like write(), it adds no newlines for you, so build them into the strings). None of this is complicated, but respecting the modes - read when you only look, append when you add, and write with care because it wipes - is what keeps file automation from ever costing you real data.

open("rooms.txt") only works if the file sits where the script is run from. Real projects have folders, so you need to describe paths. A path can be relative (data/rooms.txt, starting from the current working directory) or absolute (/Users/you/project/data/rooms.txt, starting from the disk root). Building paths by gluing strings together with slashes is fragile and breaks across operating systems; the standard library gives you two better tools:

from pathlib import Path

data_dir = Path("data")
rooms = data_dir / "rooms.txt"        # joins with the right separator
print(rooms.exists())                  # True or False
print(rooms.suffix)                    # .txt

for csv_file in data_dir.glob("*.csv"):
    print(csv_file.name)               # every CSV in the folder

The modern pathlib module treats a path as an object: you join parts with /, and you get handy methods like .exists(), .name, .suffix and .glob() for free. The older os and os.path module does the same job in a more procedural style (os.path.join, os.listdir) and you will still see it everywhere. Either way, the lesson is the same: never hand-build paths with string concatenation - let pathlib or os handle the separators, and your scripts run the same on any machine. Getting comfortable with paths is what lets a script reach across a real project's folders instead of only the one it lives in.

The single most common path bug for beginners is the working directory surprise: open("rooms.txt") looks for the file not where the script lives but where you run it from, and those are often different - which is why a script works in your editor and then fails from the terminal. Two habits defuse this. First, prefer paths built relative to a known anchor rather than bare filenames. Second, when in doubt, check: Path("rooms.txt").resolve() prints the absolute path Python is actually looking at, instantly showing you where it thinks it is. pathlib's other conveniences earn their keep in real automation too - .glob("*.csv") finds every matching file in a folder for batch work, .mkdir(exist_ok=True) creates an output folder if it is missing, and .stem, .suffix and .name pull a filename apart cleanly so you can rename or re-extension files in a loop. These are the exact tools Module 8 uses to automate whole folders; getting fluent with them now means that later work is just more of a pattern you already know.

With open, read, write and paths in hand you can already build the classic shape of a useful script - read a file in, do something in the middle, write a new file out. Here is a complete little tool that reads a rooms list, keeps only the larger rooms, and writes the result to a new file:

from pathlib import Path

src = Path("data") / "rooms.txt"       # lines like: living 18.0
kept = []

with open(src) as f:
    for line in f:
        name, area = line.split()       # split on whitespace
        if float(area) >= 14.0:         # a rule: large rooms only
            kept.append(line.strip())

with open("large_rooms.txt", "w") as f:
    f.write("\n".join(kept) + "\n")

print(f"Kept {len(kept)} large rooms")

Nothing here is new - it is a loop, a decision, some string work and two with blocks - but together they read real data off disk, apply a design rule, and leave a real file behind. That input-process-output pattern is the backbone of almost every practical script you will write. What changes in the next lesson is only the format: instead of loose text you will read structured CSV schedules and JSON settings, using the same open-and-loop foundation you just built.