Names, Values, and Assignment

Why it matters

Almost every early Python surprise — “why did changing one list change the other one?”, “why is 0.1 + 0.2 not 0.3?”, “why does is sometimes work like == and sometimes not?” — traces back to one mental model being wrong. Fix the model here and a whole category of future bugs stops being mysterious.

Mental model

Forget “a variable is a box that holds a value.” A name is a label attached to an object that exists independently of the label. price = 19.99 doesn’t put 19.99 inside something called price — it creates a float object and attaches the label price to it. price = 24.99 later doesn’t change that object; it detaches the label and reattaches it to a new one.

This distinction only becomes visible once two names can label the same object — which is exactly what plain assignment does:

first = []
second = first
first.append("milk")

print(second)

['milk']

second never received a copy of first’s list — it’s a second label on the exact same object, so a change made through first is visible through second too. This is normal, expected behavior, not a bug — see Assignment for exactly which forms of assignment share an object this way and which don’t.

Worked example: identity versus equality

Python has two different comparisons for a reason: == asks “do these have the same value?” and is asks “are these the literal same object?” They usually give different answers.

def bill_total(prices: list[float], tax_rate: float) -> float:
    subtotal = sum(prices)
    return subtotal + subtotal * tax_rate


def main() -> None:
    prices = [19.99, 5.5, 3.25]
    print(f"Subtotal: ${sum(prices):.2f}")
    print(f"Total with tax: ${bill_total(prices, tax_rate=0.08):.2f}")

    a = [1, 2, 3]
    b = [1, 2, 3]
    print(f"a == b: {a == b}")
    print(f"a is b: {a is b}")


if __name__ == "__main__":
    main()

Subtotal: $28.74
Total with tax: $31.04
a == b: True
a is b: False

a and b hold equal contents but are two separate list objects built from two separate literal expressions — a == b is True, a is b is False. id() is what is checks under the hood, and it’s how you’d confirm this directly if you wanted to.

Common mistakes: floating-point limits

print(0.1 + 0.2)
print(0.1 + 0.2 == 0.3)

0.30000000000000004
False

Check your understanding

Practice: warm-up

Predict, then check in a REPL: after x = 10, y = x, x = x + 1, what are x and y now? Explain in one sentence why y didn’t change, using the “label on an object” model rather than the “box” model.

x = 10        # x labels the int object 10
y = x         # y labels that same object 10
x = x + 1     # a new object 11 is created; x now labels it. y is untouched.

x  -> 11
y  -> 10

Practice: apply it

Write a small “unit converter” function, celsius_to_fahrenheit(celsius: float) -> float, and a main() that converts three temperatures and prints each with two decimal places. Before running it, predict whether comparing your function’s result for 0.0 against the literal 32.0 with == is safe here.

Summary

• A name is a label on an object, not a box holding a value. Assignment moves labels; it doesn’t copy objects.
• == compares value; is compares identity (literally the same object, checked via id()). They usually disagree, and == is the right default.
• Chained assignment (a = b = []) binds every target to one shared object. Multiple assignment (a, b = 1, 2) gives each target its own object from the unpacked sequence — the two look similar but behave very differently for mutable values.
• Binary floating point can’t represent every decimal value exactly — never rely on == between floats for a specific decimal result; round for display, compare with a tolerance, or use decimal/fractions when exactness matters.