Reading a Function

The one idea: A function's name is a claim the author made, not a guarantee — the body is the fact. The single question that decides whether you can trust everything downstream is: did this function change your data, or work on a copy? Tracing one call by hand answers it.

⚠️ The trap: I called clean(sales), so sales is cleaned now. That feels right and it's wrong. **If the function builds and returns a new frame instead of editing in place, a bare clean(sales) throws that result away and changes nothing — you have to capture it with sales = clean(sales).**

Once an analysis grows past a dozen lines, good code gets organized into functions — named, reusable blocks that take inputs and produce outputs. AI-generated notebooks use them heavily. For a reader, functions are mostly good news: they put a label on a chunk of logic. But they also hide one question that determines whether you can trust everything downstream: did this function change my data, or work on a copy? This lesson teaches you to read a def block (the line that defines a function), trace one call by hand, and answer that question every time.

Anatomy of a def block

def summarize_revenue(df, min_revenue=0):
    filtered = df[df['revenue'] >= min_revenue]
    return filtered.groupby('region')['revenue'].sum()

Four parts to read:

• def summarize_revenue(...) — the name. Like column aliases and variable names, it's a claim by the author, not a guarantee.
• Parameters — df and min_revenue are the inputs. Inside the function, df means whatever was passed in, not any particular DataFrame elsewhere in the notebook.
• Defaults — min_revenue=0 means the…