When Python evaluates a condition like temperature > 30, it constructs a temporary Boolean value — True or False — that exists in memory for the duration of the branch decision and is then discarded. This Boolean is not stored in any named variable (unless you explicitly store it with something like result = temperature > 30).

Python's conditional execution is implemented through jump instructions at the bytecode level. When a condition evaluates to False, Python executes a jump instruction that moves the instruction pointer to the first line after the skipped block. The skipped lines are not evaluated, not partially executed, and not considered. They are entirely bypassed. This is why it is accurate to say those lines do not exist for that execution — at the machine level, they genuinely are not visited.

The ordering of conditions in an elif chain matters — and the grading example above demonstrates why. Because the first matching condition wins and the rest are skipped, the conditions must be arranged so that more specific cases come before more general ones. In the grading example, if the conditions were reversed — testing score >= 60 first — then any score of 60 or above would immediately match, and the B, A branches would never be reached.

This ordering dependency is a common source of bugs. A trace table that evaluates each condition explicitly, with the actual values substituted in, will catch an ordering bug immediately — the wrong branch will be taken and the trace will reveal it. A programmer who tries to reason about the chain without tracing it may not notice until they test with a boundary value.

A conditional without an else is sometimes called a guard: it only takes action when a specific condition is met and does nothing otherwise. Guards are very common in professional code for input validation, early exits, and optional behaviour.

The risk of a guard is an uninitialised variable. If a variable is only assigned inside an if block with no else, and the condition is False, the variable will not exist after the block. Python will raise a NameError the moment anything tries to use it. The fix is to always assign a default value before the conditional — exactly as bonus = 0 is assigned before the if in the example above. This pattern is so reliable and readable that it is considered good practice regardless of whether you expect the condition to be False.

Python uses short-circuit evaluation for and and or. This means Python stops evaluating as soon as the result is certain — it does not always evaluate both sides.

For and: if the left side is False, the result must be False regardless of the right side. Python does not evaluate the right side at all.

For or: if the left side is True, the result must be True regardless of the right side. Python does not evaluate the right side at all.

This matters for tracing when the right side has a side effect — a function call, for instance. If the left side short-circuits, the right side's function never runs. In Grade 9 work this is rare, but it explains behaviour that can otherwise seem mysterious. When you write out the evaluation left to right in your decision row, note where evaluation stopped if it short-circuited.

not does not short-circuit — it always evaluates the expression following it and then inverts the result.

Deep nesting is widely considered a design problem in professional code. A function with four levels of nested conditionals is hard to read, hard to test, and hard to debug — not because indentation is cosmetically unpleasant, but because the number of distinct execution paths grows exponentially with each level of nesting. Two nested conditionals produce up to four paths. Three produce up to eight. Four produce up to sixteen.

Compound conditions with and are often a cleaner alternative to one level of nesting. The two programs below are logically equivalent:

# Nested version
if submitted:
    if score >= 70:
        result = "Pass"

# Compound version
if submitted and score >= 70:
    result = "Pass"

The compound version is shorter, flatter, and easier to trace. In Grade 9, both are acceptable. As programs grow more complex, preferring flat structures over nested ones becomes increasingly important for maintainability.

This distinction between chained and independent conditions is an example of a broader design question: are these conditions mutually exclusive (at most one can be true), exhaustive (at least one must be true), both, or neither?

An if/elif/else chain is both mutually exclusive and exhaustive — exactly one branch always runs. An if/elif without an else is mutually exclusive but not exhaustive — it is possible that nothing runs. Two separate if statements are neither mutually exclusive nor exhaustive. Recognising which structure a problem requires is a design skill that develops with practice. Tracing is the tool that reveals whether you chose the right structure.