02Everything is an object

In Chapter 1 we made the machine run our code. We shipped a program that printed our two-song playlist and controlled every byte on the way to the screen. But we never stopped to ask what those values actually are. That's this chapter. Here's the plan: we type one honest line — seconds = 200 — and pull it apart into the three separate moves Python really makes. Folded into that one = is the idea the whole language is built on. The question we keep coming back to is the one most tutorials skip straight past: when you write 200, where does its type live, and where do its behaviours live? The answer is the same for every value you will ever type. Each one is an object — a small parcel carrying its own value, its own type, and its own set of moves. By the end you'll know all six core value types: the three kinds of number, the booleans, that deliberate None, and frozen text versus raw bytes. And you'll be able to hand Python any value and have it tell you what it is, everything it can do, and exactly how many bytes it weighs.

01One line, three moves — everything is an object

Let's start with the smallest line that carries the whole idea. It's one honest fact about the first track on our playlist — "Blinding Lights" by The Weeknd, 200 seconds long — typed the way you'd type anything. Then we turn around and ask Python what it just made:

seconds = 200              # the length of "Blinding Lights"
title   = "Blinding Lights"

print(type(seconds))     # <class 'int'>
print(type(title))       # <class 'str'>

It reads like a single action — "put 200 into seconds." But watch closely, because Python actually makes three moves, and their order is the whole secret. Move one, the object. Somewhere in RAM — chapter 0's street of numbered boxes — Python builds an object: a small package holding the value 200 and a single pointer to its type, int. That one pointer is the object's whole claim to behaviour. The methods are not copied into the parcel; they live once on the shared int type, and every integer looks them up there on demand. Move two, the name — and move three, the binding. The = creates the name seconds and clips it onto that object in a single stroke. CPython does both as one atomic step (STORE_NAME), so there is no real instant you could catch the tag hanging empty. We split it into two beats only to keep the order visible: the object is built first, and the label is stuck on afterwards. So = never manufactures the value; it only points a label at one that already lives somewhere.

Two sibling rules follow from the same axiom. Python is case-sensitive: Title and title are two unrelated names. Asking for one you never bound is an instant error, not a shrug —

title = "Blinding Lights"
print(Title)      # NameError: name 'Title' is not defined

And indentation carries meaning: the blank space at the start of a line is grammar, not decoration, as chapter 5 makes precise. Both rules come from the same discipline. Python takes your words literally and binds them exactly.

So the founding axiom pays off immediately. Because every value is a full object that knows its own type, you never have to declare types up front — you just ask any value what it is. That axiom reaches further than it looks. The type int is itself an object (its type is type); print is an object; a whole module is an object. It really is objects most of the way down, bottoming out at type, whose own type is type. For this chapter, though, we only need the everyday values, and here is the map of them.

If every value is an object that knows its own type — what types are there? Python answers the question of "how many is 200" three different ways. Start with the numbers →

02Three kinds of number

You already met the machine's atom in chapter 0: a switch, a byte, a running time of 200 spelled out in eight lit and unlit boxes. Now Python hands that pile of switches back to you wearing three different faces, and it matters which one you're holding. There is int for whole numbers, float for numbers with a decimal point, and complex for the ones with an imaginary part. They print almost the same and they add with the same +. Underneath, though, they could hardly be more different: one grows without limit, one lives in a fixed 64-bit box, one carries two coordinates at once. This section is about telling them apart by feel.

seconds = 200            # int     — whole: "Blinding Lights" runs 200 s
minutes = 200 / 60       # float   — 3.3333333333333335, the same song in minutes
z = 3 + 4j               # complex — j is Python's imaginary unit, never i

print((10).bit_length()) # 4   → 10 is 0b1010, four bits — not 32
big = 2 ** 100           # 1267650600228229401496703205376
print(big.bit_length())  # 101 → still exact; a Python int never overflows

length = int("245")      # int() casts the text "245" → the number 245
print(seconds + length)  # 445 → it adds; "200" + "245" would have glued into "200245"

That last pair of lines is the one to watch. Chapter 1 warned you that input() always hands back text, even when the user typed digits. And text refuses to do arithmetic; it only glues. int("245") is the cure: it casts the characters into an actual number, and suddenly + means add instead of concatenate. Half of all beginner bugs are a number still wearing its text costume.

Start with the boundless one. In most languages an integer is parked in a fixed box — 32 or 64 switches, no more — and a value that outgrows its box overflows: it wraps back to zero like a six-digit odometer rolling from 999999 to 000000. Python's int flatly refuses to wrap. When a number needs more room, the object simply grows: Python bolts on another chunk of bits and keeps counting, as far as your memory allows. That's why 2 ** 100, a number with 31 digits, prints back exactly rather than as some rounded approximation. It is also why you can total the raw byte counts of a whole music library and still land on an exact integer. A 4-minute track at 320 kbps already weighs about 9.6 million bytes, and ten thousand of them go far past a 32-bit box's four-billion ceiling without ever wrapping. Slide the control below and watch the difference for yourself: the fixed 8-bit box on top can only ever hold 0–255, so push past 255 and it wraps, while the Python int underneath just grows another box.

That bit_length() lands us on a fact worth burning in, because a widely-copied note online gets it wrong: (10).bit_length() is 4, not 32. Ten in binary is 1010 — four significant bits — and Python keeps only those four. There is no hidden 32-bit box padding the number out with leading zeros. The lower row in the figure above literally draws four boxes for ten and stops. bit_length() tells you the smallest number of switches this value needs, which is why 2 ** 100 reports 101 and not some round machine width.

Why can't the float just be exact too, the way the int is? Because it made the opposite bargain. A float is always the same 64 switches, no matter what number sits in it — 3.14, or 3×10³⁰⁰, or one tenth. That fixed size is the point: a fixed size means the arithmetic is wired straight into your CPU, so floats are very fast and never grow. The price is precision. Sixty-four bits can only name about 15–17 significant decimal digits and a fixed menu of fractions, so any value off that menu — like 0.1 — gets rounded to the closest one on it.

The third face, complex, answers a need the first two can't. Some quantities are irreducibly two-dimensional and have to travel as a single value: the phasor of an AC voltage (a magnitude and a phase at once), one bin of an audio FFT (a real part and an imaginary part), or simply a point on the plane. You may go years without reaching for it, but when the problem has two axes, one number must carry both. Write 3 + 4j and you get exactly that: a single value holding a real coordinate and an imaginary one. Python uses j for the imaginary unit, not the mathematician's i (electrical engineers do the same, to avoid clashing with i for current). Ask a complex number about itself and it answers: (3 + 4j).real is 3.0, .imag is 4.0, and abs(3 + 4j) is 5.0 — the length of the arrow to that point, your old friend the 3-4-5 triangle.

Three kinds of number, and yet Python is hiding a fourth in plain sight — one wearing the costume of a word. True is quietly worth 1, False is worth 0, and lurking beside them is a deliberate nothing that is not zero at all →

03True, False, and a deliberate nothing

Two sections back you watched whole numbers grow out of switches. Now meet the smallest number type of all — so small it holds exactly two values. Python calls it bool, and its two values are True and False, each spelled with a leading capital, always. That capital is not decoration. Python is case-sensitive, so true and TRUE are not booleans; they are just names the language has never heard of, and reaching for one is an instant error. A bool is a single yes-or-no: the software echo of the one bit you met at the very bottom of the machine.

Here is the twist that catches everyone. A bool is not its own separate kind of value — it is a flavour of integer. In Python's family tree, bool is a subtype of int. True is genuinely equal to 1 and False to 0, they occupy the same 28 bytes an ordinary small integer does, and they will do arithmetic without a word of complaint. True + True is 2. That's not a party trick or a coincidence: a boolean simply is a number, printed in friendlier ink.

# a bool is a flavour of int — same value, same 28 bytes
print(True == 1)                # True
print(isinstance(True, int))    # True  — bool IS a kind of int
print(True + True)              # 2     (yes, really)
print(issubclass(bool, int))  # True

# equal in value is not the same as being the same object
one = 1
print(True is one)             # False — == compares value, is compares identity

next_track = None              # nothing queued after "Titanium"
print(type(next_track))        # <class 'NoneType'>

So a bool and an int are cut from the same cloth, but Python still draws a clean line around the two of them and a third, lonelier value. The map below is worth a slow look: bool nested inside int, and off on its own, a type with a single inhabitant.

Numbers and booleans are not the only things Python can weigh on this scale. Pour any value through bool() and it comes out as exactly one of those two. That squeeze is called truthiness, and in chapter 5 every if and while you write will lean on it. The rule is blunt and worth burning in: a value is falsy when it is empty, zero, or nothing — 0, 0.0, the empty string "", the empty list [], the empty dict {}, and None — and truthy in every other case. Drag through the zoo below and watch each value fall to one side.

Which leaves the strangest value in the language: None. It is Python's deliberate nothing — not zero, not the empty string, but a real object whose whole job is to mean "no value here, and that is on purpose." Our playlist uses it honestly: next_track = None says the queue after "Titanium" is empty, which is a genuinely different fact from a track whose title happens to be "". Because None carries no data, no two Nones could ever differ, so Python builds exactly one at start-up and hands that same object to everyone who asks. That pattern is called a singleton. It is a bare object header — 16 bytes with nothing inside, smaller even than the integer 0 (which needs 28). Ask its type and Python answers <class 'NoneType'>: a type with exactly one possible value.

Numbers, booleans, a deliberate nothing — all tidy, countable, and cheap. But a playlist is mostly text, and Python's text is carved in stone: you may read every character, yet never reshape one in place. Next we hold a string up to the light — frozen letters above, raw bytes beneath →

04Text is frozen; bytes are raw

A number knows nothing about itself. Back in chapter 0 you watched "Blinding Lights" laid across fifteen boxes in RAM, its first letter B stored not as a shape but as the bare number 66 — with a promise to explain later which code, and why. This is later. str is Python's text type, and the refinement is one sentence: a string is a sequence of Unicode code points. Unicode is the single table the whole planet agreed on. Every character that has ever been written — every Latin letter, every kanji, every emoji — gets one permanent number called its code point. B is 66, é is 233, the note 🎵 is 127,925. A string is just those numbers stood in a row, each still wearing its agreed-upon meaning.

And a string is frozen. Once Python builds one, nothing edits it in place — not you, not a method, not a single character of it. Every method that looks like it changes text quietly makes a brand-new string and hands that back, leaving the original untouched. That one rule — str is immutable — shapes half of what you'll do with text, so hold it close.

That bottom row is the other sequence type in this section. bytes is a row of raw values 0–255 with no meaning attached at all — the parcels that files on disk, packets on a network, and every MP3 of the song are actually made of. str lives only inside Python. The moment text has to leave — hit a disk, cross a socket — it must be encoded into bytes. "Blinding".encode() gives b'Blinding'. Reach into bytes with an index and you get a plain int back: b'Blinding'[0] is 66, not "B". Indexing a str, by contrast, hands you a one-character string. Two sequences, two temperaments.

But the tidy one-number-per-letter picture in that figure only holds for plain ASCII. The moment a real playlist carries a name like Beyoncé, that accented é pushes past code point 127 and no longer fits in a single byte. The encoder spreads it across two, three, even four. Drag through a few characters below and watch one code point balloon into a parcel of raw bytes.

Now watch immutability in the open. Every string method returns a new string; the one you called it on is never touched. find reports an index, or -1 for "not here" instead of raising. And a direct edit — track[0] = "B" — is simply forbidden.

# a str is a sequence of code points — and it never changes in place
track = "blinding lights"

print(track.title())                  # Blinding Lights   — a NEW string
print(track.find("titanium"))         # -1   — "not found" is -1, never a crash
print(track.replace("lights", "dark"))  # blinding dark    — also a NEW string
print(track)                          # blinding lights  — the original never moved

wire = track.encode()                 # b'blinding lights' — packed for the outside world
print(wire[0])                       # 98   — indexing bytes returns a number, not "b"
print(wire.decode())                  # blinding lights  — bytes read back into text

# track[0] = "B"    →  TypeError: 'str' object does not support item assignment

Seven types now, each frozen or fluid, each priced differently. So how do you walk up to a value you've never met — ask what it is, whether two of them are truly the same, and exactly what it weighs? →

05Interrogate any value — and weigh it

Because every value in Python is an object — a little parcel that carries its own type and its own behaviour — you never have to guess what you're holding. You can ask it. Python hands you a small interrogation kit that works on anything: a number, a string, a song length, a value you've never seen before. It's four questions and a scale. type(x) asks "what are you?" isinstance(x, int) asks "are you this kind of thing?" dir(x) asks "what can you do?" id(x) asks "where do you live?" And sys.getsizeof(x) puts the object on a scale and reads off its weight in bytes.

Point the kit at the length of "Blinding Lights" — the number 200 — and it answers int, True, an address, 28 bytes. Point it at the title string and every answer changes, because the object is different. The value isn't looking anything up in a manual; it is the manual. That's the whole payoff of "everything is an object": the answers travel inside the thing you're asking about.

Look closely at two of those questions and you'll spot Python's two shapes for "run some code on a value." len(title) is a function: a free-standing tool, and the object goes in as an argument. title.upper() is a method: behaviour that lives inside the str type itself, reached through the object with a dot. Same idea — code acting on a value — but a different address for the tool. Functions you hand the value to; methods the value carries with it.

Here's the whole kit fired at one string. Nothing to install, nothing to configure — just questions and answers:

import sys
title = "Blinding Lights"

print(type(title))              # <class 'str'>   — "what are you?"
print(isinstance(title, str))   # True            — "are you this kind?"
print(isinstance(True, int))    # True            — a bool IS an int underneath
print(len(title))               # 15              — FUNCTION: the value goes in
print(title.upper())          # BLINDING LIGHTS — METHOD: reached with a dot
print(len(dir(title)))          # 81              — every name this str carries
print(id(title))                # 140399482229104 (varies) — where it lives
print(sys.getsizeof(title))     # 56              — its weight, in bytes
print(sys.getsizeof(200))       # 28              — one small int

That dir(title) is worth a pause: it spills out 81 names the string carries — 47 of them public methods like .upper(), .find(), .split(), and the rest the dunder machinery we'll meet later. You never memorise a string's abilities; you ask it for the list. And id(title) returns a plain integer that is, in CPython, the object's actual address in RAM — the house number from chapter 0, made visible. (That address-equals-id fact is a CPython promise, not a Python one: the language guarantees only that id is a unique, unchanging integer for as long as the object lives. Chapter 3 turns it into a superpower.)

Now the scale. Every literal from this chapter has a price in bytes — step through them and watch the object announce its type, place itself in Python's family tree, and tip the scale:

You now have the tools to weigh and identify any object. But one thread from earlier is impossible to ignore: the value 200 was built first, and the name only points at its address. So what happens with b = seconds? Two names, one object — and id() can prove it. Chapter 3 follows the arrows into names & memory. →