11.12 Tuples in DevOps

Tuples and File Handling

Files store plain text, so “reading a tuple” means parsing each line and explicitly reconstructing the tuple — there’s no native tuple format on disk.

read_back = []
with open("records.txt") as f:
    for line in f:
        name, age = line.strip().split(",")
        read_back.append((name, int(age)))

>>> read_back
[('Alice', 30), ('Bob', 25)]

Writing is the reverse: unpack each tuple’s fields directly in the write loop.

records = [("Alice", 30), ("Bob", 25)]
with open("records.txt", "w") as f:
    for name, age in records:
        f.write(f"{name},{age}\n")

csv.writer accepts any iterable per row, including tuples directly — and csv.reader’s rows can be converted to tuples with tuple(row) if immutability is wanted downstream.

>>> import csv
>>> with open("data.csv") as f:
...     rows = [tuple(row) for row in csv.reader(f)]
...
>>> rows
[('Alice', '30'), ('Bob', '25')]

Five Places Tuples Are the Natural Fit

Specifically because the data they hold should never accidentally change.

Configuration Data

Fixed connection settings, unpacked directly into named variables.

>>> DB_CONFIG = ("localhost", 5432, "mydb")
>>> host, port, dbname = DB_CONFIG
>>> host, port, dbname
('localhost', 5432, 'mydb')

AWS Regions

A fixed allowlist of valid regions — a tuple communicates “this list should never change at runtime” more clearly than a list would.

>>> AWS_REGIONS = ("us-east-1", "us-west-2", "eu-west-1")
>>> "us-east-1" in AWS_REGIONS
True

Port Numbers

>>> HTTP_PORTS = (80, 443, 8080)

Server Details

A single server’s fixed attributes, bundled and unpacked as one record.

>>> server = ("web01", "10.0.1.5", "running")
>>> name, ip, status = server
>>> name, ip, status
('web01', '10.0.1.5', 'running')

Log Records

A single parsed log entry as an immutable record, safe to pass around without worrying about accidental modification — the same shape used for 9.12 Strings in DevOps and AWS’s regex capture groups.

>>> log_record = ("2026-07-13", "10:22:05", "ERROR", "Connection refused")
>>> date, time, level, msg = log_record
>>> level, msg
('ERROR', 'Connection refused')

Quick Interview Answer

“Tuples show up in DevOps code anywhere a value is fixed by design and shouldn’t be accidentally mutated later in the script — configuration bundles unpacked into named variables, an allowlist of valid AWS regions or ports, a single server’s fixed attributes, or a parsed log line’s fields. The common thread is unpacking: host, port, dbname = DB_CONFIG is both more readable and safer than indexing into an unnamed sequence with config[0], config[1], since it documents what each field means at the point of use.”

Common Mistakes

• Using a list for a fixed allowlist (valid regions, valid ports) when a tuple would both perform slightly better and communicate that the collection is not meant to change.
• Indexing into a config or record tuple positionally (server[0], server[2]) throughout a codebase instead of unpacking once into named variables — harder to read and fragile if the tuple’s shape ever changes.
• Forgetting every field parsed from a file or CSV row starts as str, even inside a tuple — the age in ("Alice", "30") needs explicit conversion (see 8.1 Introduction to Type Conversion) before arithmetic.