Sensors With a Memory Limit

# labs/sensor_log.py
import random

def simulate_temperature() -> float:
    return round(random.uniform(20.0, 30.0), 1)

def simulate_humidity() -> float:
    return round(random.uniform(40.0, 70.0), 1)

def simulate_distance() -> float:
    return round(random.uniform(5.0, 100.0), 1)

def read_sensors() -> dict:
    return {
        "temperature_c": simulate_temperature(),
        "humidity_pct": simulate_humidity(),
        "distance_cm": simulate_distance(),
    }

if __name__ == "__main__":
    random.seed(0)
    print(read_sensors())

$ uv run python labs/sensor_log.py
{'temperature_c': 28.4, 'humidity_pct': 62.7, 'distance_cm': 45.0}

Chapter 27's move, applied to inputs: simulate first, so everything above the sensors can be built and tested at your desk. Each simulator returns what the real part will return (a rounded float in a plausible range), so when a real thermometer arrives in volume 4 it replaces one function body and nothing above it changes. The reading is a plain dict with named fields, chapter 2's habit of carrying state in dictionaries again. The random.seed(0) is only there so your first run matches the page.

import json
import time
from pathlib import Path

def read_sensors() -> dict:
    return {
        "temperature_c": simulate_temperature(),
        "humidity_pct": simulate_humidity(),
        "distance_cm": simulate_distance(),
        "timestamp": time.time(),
    }

def log_sensor_reading(reading: dict, log_path: Path,
                       max_entries: int = 1000) -> int:
    log_path.parent.mkdir(parents=True, exist_ok=True)
    entries = []
    if log_path.exists():
        with open(log_path) as f:
            entries = json.load(f)
    entries.append(reading)
    entries = entries[-max_entries:]
    with open(log_path, "w") as f:
        json.dump(entries, f, indent=2)
    return len(entries)

if __name__ == "__main__":
    log = Path("glados/data/sensor_log.json")
    for _ in range(12):
        count = log_sensor_reading(read_sensors(), log, max_entries=5)
    print(f"writes: 12, entries stored: {count}")

$ uv run python labs/sensor_log.py
writes: 12, entries stored: 5

Twelve writes, five survivors: entries = entries[-max_entries:] runs on every write, so the array can never exceed the cap; the seven oldest readings fell off in age order, no cleanup code involved. The slice is safe below capacity too: [-1000:] on a three-item list returns all three, so one line handles an empty log, a half-full one, and a full one. The timestamp is time.time(), a Unix timestamp: seconds since 1970 as one float, the numeric cousin of chapter 11's sortable UTC strings; the next stage shows what the numeric form buys.

SENSOR_LOG = Path("glados/data/sensor_log.json")

def main() -> None:
    for i in range(3):
        reading = read_sensors()
        stored = log_sensor_reading(reading, SENSOR_LOG)
        print(f"Reading {i + 1} ({stored} stored): {reading}")
        time.sleep(0.1)

if __name__ == "__main__":
    main()

$ uv run python labs/sensor_log.py
Reading 1 (1 stored): {'temperature_c': 24.9, 'humidity_pct': 55.4, 'distance_cm': 88.2, 'timestamp': 1787270501.104521}
Reading 2 (2 stored): {'temperature_c': 26.3, 'humidity_pct': 47.1, 'distance_cm': 12.6, 'timestamp': 1787270501.2051334}
Reading 3 (3 stored): {'temperature_c': 21.7, 'humidity_pct': 63.8, 'distance_cm': 74.3, 'timestamp': 1787270501.3056214}

Your values and timestamps will differ; the pattern will not. The time.sleep(0.1) looks decorative and is load-bearing: without it, all three reads fire within the same fraction of a millisecond and their timestamps come out nearly identical, which makes ordering ambiguous and rate-of-change a division by almost zero. In production this pause becomes your sampling interval; here it is short so the demo finishes now. In your own output each timestamp is about 0.1 higher than the last: the sleep, visible in the data.

def read_log(log_path: Path) -> list[dict]:
    if not log_path.exists():
        return []
    with open(log_path) as f:
        entries = json.load(f)
    entries.sort(key=lambda e: e["timestamp"])
    return entries

if __name__ == "__main__":
    entries = [
        {"temperature_c": 22.4, "timestamp": 1787270615.4},
        {"temperature_c": 21.5, "timestamp": 1787270495.1},
        {"temperature_c": 22.0, "timestamp": 1787270555.2},
    ]
    entries.sort(key=lambda e: e["timestamp"])
    span = entries[-1]["timestamp"] - entries[0]["timestamp"]
    drift = entries[-1]["temperature_c"] - entries[0]["temperature_c"]
    print(f"oldest first: {[e['temperature_c'] for e in entries]}")
    print(f"span: {span:.1f}s, drift: {drift:+.1f} C")

$ uv run python labs/sensor_log.py
oldest first: [21.5, 22.0, 22.4]
span: 120.3s, drift: +0.9 C

The writer appends in order, so why sort at all? Because "the file happens to be ordered" is an accident, and "the reader guarantees order" is a contract. The moment a second process writes the same log, or two files get merged, the accident ends; read_log costs one line and makes every consumer immune. This is where the float timestamp earns its keep: Unix time sorts with plain numeric comparison, no parsing, no timezone, and subtraction gives seconds directly; the span and drift lines are the whole trend calculation. Two sort keys now live in the project: UTC strings where a human reads rows, Unix floats where code does arithmetic.