Chapter 3 — Programming foundations
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Why technologists script"]
N2["3.2 Lists, dictionaries and sets"]
N3["3.3 Working with text"]
N4["3.4 Clear output"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Why technologists script"]
N2["3.2 Lists, dictionaries and sets"]
N3["3.3 Working with text"]
N4["3.4 Clear output"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Why technologists script]
|
v
[3.2 Lists, dictionaries and sets]
|
v
[3.3 Working with text]
|
v
[3.4 Clear output]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write simple Python scripts with the standard library; (2) process lists and text; (3) make output clear.
3.1 Why technologists script
Technologists repeat many tasks: checking device lists, comparing configurations, counting log entries. Doing these by hand is slow and error-prone. Short Python scripts make them fast and repeatable. Tomás's course uses only the Python standard library, so scripts run on any machine without installing anything, and all lab data are synthetic. His first scripts are short and focused, such as counting how many devices in the inventory have no named owner, and he learns to read every line he writes so that he can trust the result.
3.2 Lists, dictionaries and sets
Python's basic structures fit network tasks well. A list keeps items in order, such as firewall rules. A dictionary maps keys to values, such as device names to addresses. A set holds unique items and supports comparisons, such as which approved services were not seen and which seen services were not approved. Tomás practises choosing the right structure: using a set to compare two inventories takes one line and avoids mistakes that come from looping through lists by hand and missing duplicates.
3.3 Working with text
Logs and configuration files are text. Tomás learns to split lines into fields, strip extra spaces, convert numbers and skip blank lines. He handles errors by counting lines that do not match the expected format and reporting the count, rather than letting the script crash or quietly ignoring them. He also learns never to run text from logs as commands, because logs can contain text that a user or attacker typed. Treating input as data, never as instructions, is a basic safety rule for scripts.
3.4 Clear output
A script's output should answer a question. Tomás prints aligned columns with short headers, a summary line with totals and percentages, and a note of any skipped input. He avoids printing hundreds of lines when a short list of exceptions would do. Clear output helps Gareth, who will use some of Tomás's scripts after the placement, and it makes errors easier to spot, because a reader can check that the summary matches the listed items. Good output is part of good tooling, not decoration.
Worked example
Tomás's script counts three devices with no owner and reports one malformed inventory line.
Synthetic case. Data are synthetic.
Errors and limits
Scripts that hide skipped input can produce confident but incomplete results.
Exercises
- EX007 — Set comparison use. What task suits a set comparison? Rubric: 3 = approved versus observed items, finding differences;; 2 = comparisons;; 1 = ordering;; 0 = none.
- EX008 — Log text safety. Why must log text never be run as commands? Rubric: 3 = may contain text typed by users or attackers;; 2 = unsafe;; 1 = slow;; 0 = none.
- EX009 — Skipped input. How should a script handle lines in the wrong format? Rubric: 3 = count and report them;; 2 = report;; 1 = crash;; 0 = none.
Synthesis
Small, clear stdlib scripts make routine checks fast, repeatable and trustworthy.
Continue studying — chapter 03 of 30
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →