Names and values

Your programs so far run from top to bottom and forget everything, which is the whole limit on what they can do. This lesson gives them a memory. It rests on one small idea that almost everyone misreads the first time, which is what the equals sign actually does.

The equals sign is an instruction

savings = 250

Read that out loud as "savings gets 250", not "savings equals 250". It's a command, not a statement of fact. It tells Python to do two things, in a fixed order:

1. Work out what is on the right, completely.
2. Make the name on the left refer to that result.

Right side first, then bind. That order is all there is to it, and once you have it, the line beginners most object to stops being strange:

total = total + 5

As a claim about arithmetic it's nonsense, and people say so. As an instruction it's straightforward. Work out the right side, which needs the value total has right now, say 20, and comes to 25. Then make total refer to 25. The old value is replaced, not amended.

That question, "what is each name worth right now", is the one you'll ask about your own code more than any other. When you can't answer it, put the program into Python Tutor, which runs it a line at a time and draws every name and value on screen.

Four kinds of value

Every value in Python has a type, and the type decides what the operators do to it. Four of them carry this whole course.

You can ask about any value with type():

>>> type(250)
<class 'int'>
>>> type("250")
<class 'str'>

Those two aren't the same thing, and the difference isn't cosmetic. 250 is a quantity you can do arithmetic with. "250" is three characters that happen to look like one.

Watch what + does to each:

>>> 2 + 2
4
>>> "2" + "2"
'22'

+ isn't being inconsistent. It means "add" for numbers and "join end to end" for text, and it picks by looking at what it's been given. So there is no arithmetic in the second line at all; it glues two characters together and hands you the result.

* makes the same kind of choice. Between two numbers it multiplies; between text and a whole number it repeats:

>>> "ab" * 3
'ababab'

That one's worth remembering, because it means a program can do something entirely reasonable with text you thought was a number, and never complain.

Getting something in from outside

input() shows a prompt, waits for the person to type a line, and hands back what they typed. Here's the part that catches everyone:

>>> reply = input("How many? ")
How many? 7
>>> type(reply)
<class 'str'>

input() always gives you a string. Always. It doesn't look at what was typed and decide. Even when the user types 7 and means seven, you get the one-character text "7".

So this program is broken:

year = input("Year you were born: ")
print(2026 - year)

Year you were born: 1999
Traceback (most recent call last):
  File "/home/you/age.py", line 2, in <module>
    print(2026 - year)
          ~~~~~^~~~~~
TypeError: unsupported operand type(s) for -: 'int' and 'str'

Read that the way lesson 1 taught you: bottom line first. TypeError means the types were wrong for the operation. The message names both of them and even names the operator, -. Python's telling you it has an int on one side and a str on the other and won't guess which one you meant to convert. (The squiggles marking the failing part of the line arrived in Python 3.11, so on an older one you'll see the same error without them.)

That refusal to guess is deliberate, and Python states it as a principle: explicit is better than implicit, the second line of the Zen of Python.⁵ You can read the whole thing by running import this.

Notice, too, that the prompt appeared on screen before the traceback. The program ran, and then it failed. That makes this the second kind of error from lesson 1, the sort found during the run rather than before it.

The fix is to convert, with int() for whole numbers or float() for numbers with a decimal point:

year = int(input("Year you were born: "))
print(f"You turn {2026 - year} this year.")

Year you were born: 1999
You turn 27 this year.

Read int(input(...)) from the inside out. input() runs first and produces "1999". Then int() takes that and produces the number 1999.

The f before the opening quote makes it an f-string. Anything in curly brackets inside it is worked out and dropped into the text. Without the f you'd get the literal characters {2026 - year} printed, which is a mistake worth making once so you recognise it next time.

A number that is not quite the number

Now try it:

>>> 0.1 + 0.2
0.30000000000000004
>>> 0.1 + 0.2 == 0.3
False

This isn't a bug in Python, and it isn't a bug in your machine. float values are stored as binary fractions, and one tenth cannot be written exactly in binary, in the same way that one third cannot be written exactly in decimal. You'd need 0.333... forever. So 0.1 is stored as something extremely close to a tenth, and the tiny gaps add up.

Three ways to live with it. Compare with a tolerance, using round():

>>> round(0.1 + 0.2, 2) == 0.3
True

Or, when the values are money, work in whole units of the smallest denomination. Count pence rather than pounds, cents rather than dollars, and use int throughout, which sidesteps the problem instead of managing it. Python also ships a decimal module that does base-ten arithmetic exactly, at the cost of being slower and wordier. Any of the three is a real answer. float for money is not.

This isn't Python's problem, either. It's the behaviour of IEEE 754 binary64, the number format nearly every language reaches for when it needs decimals, so C, Java and JavaScript all print the same thing. If you want the full story, the official documentation has a whole chapter on it.¹

What people get wrong

Reading = as a claim of equality. This is where nearly every confusion in this lesson starts. It's an instruction, and the order is right side first.

Expecting b = a to keep tracking a. It doesn't, as you predicted above. It copies the value across once, and after that nothing you do to a reaches b.

Expecting input() to notice a number. It never does. If you want a number, say so with int() or float().

Expecting "2" + "2" to be 4. The + looks at what it's given. Two strings get joined.

Using is when you mean ==. This one deserves its own demonstration, because the usual advice ("is sometimes works by accident on small numbers") understates it. Put these three lines in a file, and then, separately, type the same three lines at the >>> prompt:

c = 257
d = 257
print(c is d)

Nothing about the numbers changed. is doesn't ask whether two values are equal. It asks whether they are the same object, and whether Python bothered to reuse one object here depends on how your code was compiled, which in turn depends on whether you ran a file or typed at the prompt.

Now try it with 5 instead of 257 and you get True both ways, because CPython keeps a single shared object for every small integer and hands the same one out each time.⁴ So the answer moves with the size of the number and with how you ran the code. Those are implementation details you should never have to think about, and a comparison whose answer depends on them isn't a comparison you can build on.

So use == to compare values. Use is only with None, where "the same object" is what you actually mean, and where the answer never depends on how you ran the code.

Practice

x = 5
y = x
x = x + 1
print(x)
print(y)
print("x" + "y")
print(str(x) + str(y))

Connections

Lesson 1 gave you the loop of run it and read the error. This lesson added TypeError to the two you already knew, and it arrived exactly as lesson 1 said it would, with output on screen before it, because the file parsed fine and then failed during the run.

Next comes making choices. That needs bool, which you met in the type table above and haven't used yet, and it brings the fourth error, ValueError, which is what int() raises when the text it's handed isn't a number at all. The checkpoint above has already shown you one.

Go deeper

• Think Python, chapter 2, "Variables and Statements", free online. Allen Downey is unusually careful about the difference between a statement and an expression, which is the formal version of the idea this lesson opened with.
• The Python tutorial, chapter 15, on floating point. Short, and it'll settle the 0.1 + 0.2 question for good.
• Python Tutor. Paste the three-line a, b example in and step through it. Seeing the arrows move is worth more than another paragraph from me.

Sources

1. The Python Tutorial, chapter 3, "An Informal Introduction to Python", and chapter 15, "Floating-Point Arithmetic: Issues and Limitations", Python 3.14 documentation. Types, operators, and the binary-fraction explanation of 0.1 + 0.2.
2. PEP 8, Style Guide for Python Code. The snake_case naming convention.
3. Allen B. Downey, Think Python, 3rd edition, 2023, chapter 2, "Variables and Statements". Free online under CC BY-NC-SA 4.0. Linked, not adapted.
4. All code output in this lesson was run on CPython 3.14.7 and pasted from the terminal, including the TypeError traceback and the is comparison giving different answers in a file and at the prompt.
5. PEP 20, The Zen of Python, Tim Peters, 19 August 2004. "Explicit is better than implicit", the second of its nineteen lines.