Why Structured Data Matters for Automation

Text a script can trust

Raw show command output is text meant for a person to read: column widths that shift, headers that vary slightly between platforms, blank lines in inconsistent places. A script can pick data out of it, but every quirk of that output is something the script has to work around.

Structured data is the opposite: text with an explicit, predictable shape — clear boundaries between fields, a consistent way to represent a list versus a single value versus nothing at all. {"hostname": "SW1", "ip": "10.10.10.1"} isn't just readable, it's parseable — a script can turn it directly into a dictionary without guessing where one field ends and the next begins.

You've already been working with structured data all module — every device dictionary and every list of devices from "Python for Network Engineers" was structured data, living in Python's memory while the script ran. This lesson is about what happens to that same data once the script needs to save it, share it, or hand it to something that isn't Python at all.

A useful way to think about it

Structured data isn't a new idea — it's the same shape you've already been using as Python dicts and lists. This module is about the different ways to write that shape down as text, so it can live somewhere other than inside a running script.

The round trip

A Python dictionary only exists while the script that created it is running — the moment the script ends, it's gone. If you want an inventory to still be there tomorrow, or want a teammate who's never opened Python to read your report, that data has to leave memory and become a file on disk.

Python dict / listin memory, while the script runs
Write to a filethe data becomes text — JSON, YAML, or CSV
File on diskcan be saved, emailed, version-controlled, read by other tools
Read from the filetext is turned back into structured data
Python dict / listback in memory, ready to use again

This round trip — memory to file and back — is exactly what the rest of this module teaches: how to write Python data out as JSON, YAML, or CSV, and how to read each of them back in.

Quick checkConcept check

Which of these best describes 'structured data,' as this lesson uses the term?

Any text file, regardless of formatText with an explicit, predictable shape that a script can reliably parse — not just something a person can readData that only exists inside a running Python scriptAny data returned by a network device

Quick checkConcept check

Why isn't a Python dictionary living in memory enough on its own for most automation tasks?

Dictionaries can't hold more than a few keysIt disappears the moment the script that created it finishes running — it has to become a file to persist or be sharedDictionaries can't hold device dataPython dictionaries are already a file format

Three formats, three different strengths

You'll go deep on each of these in the next three lessons — for now, just the shape of the map:

JSON — nests naturally (dictionaries inside dictionaries, lists of dictionaries), and is what most device APIs and modern CLI | json output already speak. Best when data has real structure and needs to move between programs.
YAML — represents the same kind of structured data as JSON, but written to be easy for a person to read and hand-edit. This is why Ansible playbooks, Nornir inventories, and countless config files are YAML rather than JSON.
CSV — the simplest of the three: a flat table, one row per item, the same columns every time. Excellent for a straightforward device inventory list; awkward the moment the data isn't flat.

Quick checkScenario

An engineer needs to hand a device inventory to a teammate who doesn't use Python, so they can review it in a spreadsheet. What's more useful: the printed output of a Python script, or the same data saved to a file?

The printed output — it's already visible on screenSaving it to a file, so the teammate has something they can actually open, edit, and keepNeither — spreadsheets can't be generated from Python dataIt doesn't matter, since the teammate doesn't use Python anyway

Quick checkMyth check

Does one of JSON, YAML, or CSV replace the need for the other two?

Yes — JSON is strictly better and should always be usedYes — YAML is strictly better and should always be usedNo — each is better suited to a different job, which is exactly what the rest of this module coversNo — none of them are actually used in real network automation

Key takeaways

Structured data has a predictable, explicit shape that a script can reliably parse — unlike raw, free-form command output.
A Python dict or list only exists in memory while its script runs; writing it to a file is what lets it persist and be shared.
The core pattern this module teaches: Python data → written to a file → read back into Python data, for JSON, YAML, and CSV.
JSON nests naturally and is common in device APIs; YAML is written for humans to hand-edit; CSV is a simple flat table.
The right format depends on the shape of the data and who (or what) needs to read it — not one universal choice.

What you'll learn

Text a script can trust

The round trip

Three formats, three different strengths