6.1Python building blocks and interpreting a script

When Python appears in ENCOR's domain 6, what is expected is not implementation skill as a programmer but reading skill as an operator. The exam does not ask "what is a variable"; it presents a dozen-odd lines of a script and asks you to predict its output or point out why it does not behave as intended. Automation scripts are remarkably formulaic: nearly all share the skeleton "iterate a device inventory (a list), inspect each device's attributes (a dictionary), and act only on those matching a condition." Once you hold that skeleton, and build the habit of checking three breaking points—whether the indentation places a line inside or outside the loop, whether the dictionary really has that key, and whether the function returns a value—you can reason about a script you have never seen.

6.1.1Elements that hold data: variables, lists, dictionaries

• A list ([]) is an ordered, variable-length sequence, used to enumerate items of the same kind, as in devices = ["r1", "r2", "r3"]. Elements are indexed starting at 0 (devices[0] is "r1"), so reasoning "there are three, therefore devices[3]" raises an out-of-range error. In network automation, device inventories, interface lists, and result sets are lists.
• A dictionary ({}) maps keys to values, bundling one device's attributes as in dev = {"host": "r1", "ip": "10.0.0.1"}. You read it with dev["ip"], but looking up a missing key with square brackets raises KeyError and halts the script. To avoid halting, the idioms are dev.get("ip") (yielding None when absent) or an existence check with if "ip" in dev:—a difference that matters with real inventories where fields are present for some devices and not others.
• The practical point is that lists and dictionaries nest: a "list of dictionaries" such as inventory = [{"host": "r1", "role": "core"}, {"host": "r2", "role": "access"}] is the standard shape of API responses and inventories. With that shape, for dev in inventory: takes one device at a time and dev["role"] tests an attribute—so do not misread the correspondence: the outer list is "how many devices," the inner dictionary is "one device's attributes."

6.1.2Elements that control flow: loops, conditionals, indentation

• A loop (for dev in inventory:) processes one element of a sequence at a time. In Python, indentation literally is the block boundary, playing the role braces play elsewhere. Consequently one level of indentation decides whether a line is inside or outside the loop, changing its execution count from "once per device" to "once total"—a summary print inside the loop fires per device, while outside it fires once at the end.
• A conditional (if / elif / else) branches on a test. The classic mistakes here are confusing = (assignment) with (comparison) and case mismatches ("Core" "core" is false). Also, continue skips only the current iteration and moves to the next element, whereas break terminates the loop entirely—so writing break when you meant "skip non-matching devices" ends all processing at the first non-match.
• A function (def check(dev):) names a routine for reuse. If you need a value back you must write return; a function without return yields None—so if you wrote result = check(dev) but the function only prints, result is None and any later if result: is always false. "It appeared on screen" does not mean "a value was returned"—the most-missed point in script diagnosis.

Suppose the operations team says, "I wrote a script to build a backup target list limited to core switches, but it does not behave as expected," and shows you this code. After inventory = [{"host": "sw1", "role": "core"}, {"host": "sw2", "role": "access"}, {"host": "sw3", "role": "core"}], they prepare targets = [], define def is_core(dev): whose body is only if dev["role"] "core": print(dev["host"]), call it with for dev in inventory: if is_core(dev): targets.append(dev["host"]), and finish with print(len(targets)). The symptom: running it prints sw1 and sw3 on screen, yet the final count shows 0. The biggest pitfall here is concluding "it printed, so the function judges correctly"—is_core has no return. The function does print, but it always returns None to its caller, None evaluates as false, so targets.append(...) never executes, and len(targets) is therefore 0. The fix is to change the print into return True (and return False when not matching), making the principle that "displaying" and "returning" are different acts the very key to the diagnosis. If the person instead suspected "maybe inventory is written wrong" and changed for dev in inventory: to for dev in inventory[0]:, they would iterate the first device's dictionary rather than the outer list, so dev would hold key strings ("host", "role") and dev["role"] would raise TypeError—a misreading of the structure in which the outer level is a list and the inner one a dictionary. As another common symptom, indenting print(len(targets)) inside the loop prints the count once per device (three times) instead of once at the end. When you see a "wrong number of times" symptom rather than an error, the standard move is to suspect the indentation level first. And writing the test as if dev["role"] = "core": fails to start at all with a syntax error, while if dev["Role"] "core": halts on the very first device with a KeyError—the goal of this section is to work backward from the symptom (nothing runs / halts midway / count is off / always empty) to the breaking point.

6.1.3Section summary

• The standard shape of an automation script is iterating a "list of dictionaries" with for and filtering with if; the starting point is not misreading outer = list of devices, inner = dictionary of attributes
• Script defects cluster into three points—indentation (loop extent), key existence (KeyError), and presence of return (None)—and you can work backward from the symptom to the breaking point
• "Displaying" and "returning" are different: print gives you diagnostic material but never makes the caller's test true