Functions, tracebacks, and repair

Functions give a repeated operation a name, inputs, and a return value. Write a small function before a rule grows branches. Then use the traceback as a report about the function's violated assumption. Read it from the bottom upward, identify the file and line that failed, and inspect the values that reached it. NameError often means a spelling or scope mistake, TypeError a mismatched contract, KeyError an unhandled input shape, and FileNotFoundError a virtual path contract. The class is a clue, not a verdict. Add a small reproduction before editing a large program.

Use the app's small-run editor to isolate library behaviour. A breakpoint() call is not required in Pyodide labs, where a bounded print or assertion makes the state visible without changing device settings. Keep a failing input in a labelled fixture once you have found it. A bug you cannot reproduce will return.

Separate observation from interpretation. Print or log the input type and a bounded representation, then assert the invariant you expected. Do not print tokens, passwords, or complete personal records. A minimal failing example that removes networking and time makes the repair smaller and the test permanent.

Micro-lab in the app

Predict, run, change or break, explain: pass text to this function and identify the traceback's violated input contract.

def percentage(part, whole):
    return part / whole * 100
print(percentage(3, 8))