⚡ IT Wisdom I told my team to fix the broken DNS server. It took a while, but they finally came around.
Skilled Practitioner
4249 XP 1751 to Expert
Learn  /  Python Fundamentals  /  Unit 13

Unit 13 — Capstone — Build a Network Inventory Tool

Units
✓ Whetting Your Appetite — Why Python for Networking? ✓ Using the Python Interpreter ✓ An Informal Introduction to Python — Network Basics ✓ Control Flow — Making Decisions in Network Scripts ✓ Data Structures — Modeling Network Inventories ✓ Modules — Organizing Your Network Scripts ✓ Input and Output — Reading and Writing Network Data ✓ Errors and Exceptions — Building Reliable Network Scripts ✓ Classes — Modeling Network Devices as Objects ✓ Standard Library Part I — Tools Every Network Script Needs ✓ Standard Library Part II — Logging, Formatting, and Counting ✓ Virtual Environments and Packages — Isolating Your Dependencies ✓ Capstone — Build a Network Inventory Tool

What Now?

You have finished the Python fundamentals. Before moving on to real network automation tools in Module 2, a few things worth knowing:

The Python Package Index (PyPI) is at pypi.org. It has over 500,000 packages — tools for SSH automation, REST API calls, parsing, data analysis, and anything else you need. In Module 2, you will install several of these.

PEP 8 is the Python style guide. It defines how to format code — naming conventions, indentation, line length, spacing. Most professional Python code follows it. Read it once at peps.python.org/pep-0008.

The official documentation at docs.python.org has a complete reference for every built-in function and standard library module you have used in this module.

Capstone Project — Network Inventory Tool

This capstone pulls together everything you have learned in Module 1. You will build a four-file command-line tool that:

  1. Loads device records from a JSON file
  2. Validates each record — required fields, IP format, VLAN range
  3. Creates NetworkDevice objects from valid records
  4. Logs the outcome of each record (INFO for success, WARNING for failures)
  5. Writes a formatted inventory report to a text file

There is no new Python syntax here. Every piece of this tool uses something you have already built in a previous unit. The capstone tests whether you can put it together independently.

Project Structure

capstone/
├── device.py          # NetworkDevice class
├── validator.py       # InvalidDeviceRecord exception + validate_device()
├── report.py          # write_report() function
├── main.py            # entry point — loads, validates, reports
└── devices.json       # input data

Each file has exactly one responsibility. This is the same principle as Python's modules — split code by what it does, not by how much you can fit in one file.

What Each File Must Do

device.py

Defines NetworkDevice. The class stores five attributes: name, ip, device_type, site, and vlan. It exposes two methods:

  • get_summary() — returns a formatted one-line string describing the device
  • to_dict() — returns a dictionary with keys name, ip, type, site, vlan

Both methods must include a one-line docstring.

validator.py

Defines InvalidDeviceRecord(Exception) — a custom exception for bad records.

Defines validate_device(record) — raises InvalidDeviceRecord if: - Any of these fields is missing: name, ip, type, site, vlan - The ip value does not match four dot-separated groups of digits - The vlan value is not between 1 and 4094

Returns True if all checks pass.

report.py

Defines write_report(devices, filename) — writes a text report to filename. The report has: - A header line: Network Inventory Report - A datestamp line: Generated: <timestamp> - A separator line of 60 = characters - One get_summary() line per device - Another separator line - A total line: Total: X devices

main.py

The entry point. It: 1. Configures logging with format %(levelname)s %(message)s at INFO level 2. Loads devices.json using json.load() 3. For each record: calls validate_device(), creates a NetworkDevice on success (logs INFO), logs WARNING on failure 4. Calls write_report() to write inventory_report.txt 5. Reads inventory_report.txt and prints every line

Design Decisions

Why four files instead of one?

A single 100-line file works fine for a script. But when something breaks — and it will — you want to look in one place. validator.py failing means the validation logic is wrong. report.py failing means the output format is wrong. One file per responsibility makes debugging faster.

Why logging instead of print()?

print() always runs. With logging, you set a level and everything below it is silent. In production you set INFO and see summaries. While debugging you set DEBUG and see everything. Same code, different behaviour — no editing required.

Why a custom exception?

KeyError or ValueError could both be raised by bad data. A custom InvalidDeviceRecord exception tells the next developer (or future you) exactly what went wrong without reading the code. Specific errors make scripts easier to maintain.

Summary

  • Module 1 is complete — you now have the Python fundamentals to build real tools
  • This capstone integrates: classes (Unit 9), exceptions (Unit 8), file I/O (Unit 7), logging (Unit 11), regex (Unit 10), and modules (Unit 6)
  • Module 2 applies the same patterns to real devices over SSH, REST APIs, and network management platforms
  • Explore PyPI, read PEP 8, and keep the official docs open as a reference