Control Flow: Solutions

# exercise_1.py
def find_factor(n):
    for d in range(2, n):
        if n % d == 0:
            print(f"{n} = {d} * {n // d}")
            break
    else:
        print(f"{n} is prime")

find_factor(97)
#: 97 is prime

The loop tries every d from 2 up to 96 and finds no factor, so it does not reach break. The for’s else clause runs when the loop finishes without a break, so it prints 97 is prime.

If you keep the chapter’s one-line conditional expression and add if n % 2 == 1: odd_count += 1 after it, the test sees the new n, not the value n held when the step began. The count then includes the 1 that ends the sequence, and collatz_sequence(10) returns (6, 2). The solution splits the conditional expression into an if/else statement, so the odd case has a branch of its own and the count shares the test that chooses 3 * n + 1.

# exercise_2.py
def collatz_sequence(n):
    steps = 0
    odd_count = 0
    while n != 1:
        if n % 2 == 0:
            n = n // 2
        else:
            n = 3 * n + 1
            odd_count += 1
        print(n)
        steps += 1
    return steps, odd_count

print(collatz_sequence(10))
#: 5
#: 16
#: 8
#: 4
#: 2
#: 1
#: (6, 1)

Six steps total, and only one of them (5 -> 16) starts from an odd n. odd_count increments in the else branch, the one that takes 3 * n + 1, and that branch runs only when n is odd.

# exercise_4.py
def checked_divide(a, b):
    if b == 0:
        raise ValueError("Divide by zero")
    return a / b

def divide_and_report(a, b):
    try:
        checked_divide(a, b)
    except ValueError as e:
        print("caught:", e)
    else:
        print("no exception")
    finally:
        print("finally always runs")

try:
    divide_and_report(1, "x")
except TypeError as e:
    print("escaped:", type(e).__name__)
#: finally always runs
#: escaped: TypeError

Let an unmatched exception through. divide_and_report(1, "x") raises TypeError inside checked_divide(), because Python cannot divide an int by a str. The except clause names ValueError, so the TypeError passes it by. The finally block still runs: finally runs whatever kind of exception is in flight. The else clause does not run here: it belongs to the case where the try block finishes cleanly.

Catch the escape at the caller. The TypeError keeps propagating up past divide_and_report(), so this listing wraps the call in its own try/except TypeError to show the exception escaping. An interactive session or an outer caller sees the TypeError escape the same way.

If you add the new case at the bottom of the match, below case _, Python rejects the file before running any of it: SyntaxError: wildcard makes remaining patterns unreachable. A wildcard matches every value, so no case after it could run, and Python treats that as an error rather than as dead code. The solution puts the three-item pattern first, above the wildcard.

# exercise_5.py
def run(command):
    match command.split():
        case ["go", direction, distance]:
            return f"moving {direction} for {distance}"
        case ["go", direction]:
            return f"moving {direction}"
        case ["quit"]:
            return "goodbye"
        case _:
            return "unknown command"

print(run("go north 3"))
#: moving north for 3
print(run("go north"))
#: moving north

Give the longer command a case. Before the new case exists, run("go north 3") returns unknown command. A list pattern matches on length as well as content, so ["go", direction] matches only a list of two items. The three-item split matches neither of the original patterns and reaches case _. The longer pattern gives a three-item list a case of its own.

Arrange the patterns. Order matters only between patterns that could both match the same value. The two go patterns cannot, so either arrangement works here.

# exercise_7.py
import textwrap
import traceback

class BadNumber(Exception):
    pass

def substituted(text):
    try:
        return int(text)
    except ValueError:
        raise BadNumber(text) from ArithmeticError(
            "no digits here")

def joining_line(e):
    for part in traceback.format_exception(e):
        line = part.strip()
        if (line.endswith("exception occurred:")
            or line.endswith("following exception:")):
            return line
    return "nothing shown above it"

try:
    substituted("seven")
except BadNumber as e:
    for chunk in textwrap.wrap(joining_line(e), 55):
        print(" ", chunk)
    print(type(e.__cause__).__name__,
          type(e.__context__).__name__)
#:   The above exception was the direct cause of the
#:   following exception:
#: ArithmeticError ValueError

Chain from a constructed cause. The prediction is the “direct cause” line, the same one explicit() produces. from sets __cause__ to whatever object follows it, and Python builds the traceback that joining_line() searches from __cause__. An exception constructed in the raise statement joins the report the same way a caught one does. from takes an expression, not a name bound by except.

Compare the cause with the context. The second print() shows that both attributes hold an exception, and different ones: __cause__ is the ArithmeticError you supplied, and __context__ is still the ValueError Python recorded on its own when raise ran inside a handler. Python reports the cause when one exists, so the context is present but invisible.

__context__ answers “what was the except block handling when raise ran,” and Python fills that attribute in whether you want it or not. __cause__ answers “what do you, the author, say explains this,” and from alone fills that one in. from None sets __suppress_context__, hiding the __context__ answer, and leaves __cause__ as None.