Choosing the Right Format for the Job

The decision, made concrete

Three lessons, three formats — here's the question that actually decides between them:

A device inventory that's just hostname/IP/platform, one row each? CSV. An Ansible-style playbook or Nornir inventory a human will open and tweak by hand? YAML. A device's full config pulled from a REST API, with nested sections for interfaces, VLANs, and routing? JSON.

Bringing it together: merging two files into one report

Real automation work often means combining data from more than one source. Here's a small, complete script that reads a CSV device inventory and a JSON site-configuration file, and merges them into a single combined report — using nothing beyond what this module and the Python module have already covered.

The inputs:

hostname,ip,site
SW1,10.10.10.1,HQ-Fl2
SW2,10.10.10.2,HQ-DC
SW3,10.10.10.3,HQ-Fl2

{
  "HQ-Fl2": "10.0.0.5",
  "HQ-DC": "10.0.0.1"
}

The script:

import csv
import json

with open("devices.csv") as f:
  devices = list(csv.DictReader(f))

with open("site_config.json") as f:
  site_config = json.load(f)

combined = []
for device in devices:
  site = device["site"]
  expected_ntp = site_config.get(site, "unknown")
  combined.append({
      "hostname": device["hostname"],
      "ip": device["ip"],
      "site": site,
      "expected_ntp": expected_ntp,
  })

with open("combined_inventory.json", "w") as f:
  json.dump(combined, f, indent=4)

print(f"Merged {len(combined)} devices into combined_inventory.json")

What it does, tying back to what you already know:

• csv.DictReader reads the flat inventory into a list of dictionaries — Lesson 4.
• json.load reads the nested site config into a Python dictionary — Lesson 2.
• for device in devices: — the loop from "Conditions & Loops," visiting every device once.
• site_config.get(site, "unknown") looks up each device's site in the config dictionary, with "unknown" as a safe fallback if a site isn't listed — so a missing site doesn't crash the script, it just gets flagged.
• combined.append({...}) builds a new dictionary per device, joining fields from both sources — the same result-collection pattern from the Python module's capstone.
• json.dump(..., indent=4) writes the merged result out as a new, readable JSON file — Lesson 2 again, now producing output instead of just reading input.

Running it prints:

Merged 3 devices into combined_inventory.json

And it creates:

[
  {
      "hostname": "SW1",
      "ip": "10.10.10.1",
      "site": "HQ-Fl2",
      "expected_ntp": "10.0.0.5"
  },
  {
      "hostname": "SW2",
      "ip": "10.10.10.2",
      "site": "HQ-DC",
      "expected_ntp": "10.0.0.1"
  },
  {
      "hostname": "SW3",
      "ip": "10.10.10.3",
      "site": "HQ-Fl2",
      "expected_ntp": "10.0.0.5"
  }
]

The choice is a design decision, not a rule

There's no single correct answer carved in stone — a small, flat inventory could reasonably live in JSON too, and plenty of real tools accept more than one format for the same kind of input. What matters is being able to reason about why a given format fits a given job, which is exactly what this module built toward: JSON for nested data moving between programs, YAML for what a person will hand-edit, CSV for flat tables — and, as this lesson showed, combining more than one when a real task calls for it.

Where this module leaves you

You can now read and write the three formats that carry almost all real network automation data — JSON for nested data exchanged with programs and APIs, YAML for configuration a person hand-edits, and CSV for flat inventory lists — and, just as importantly, reason about which one fits a given job. Combined with the Python module before it, you have everything needed to read a real inventory, process it, and produce a real report, in the actual formats network automation tooling uses.