12Data with behaviour

In Chapter 11 we mastered the object's memory. We sized it to the byte, and with __slots__ we even packed its fields wall-to-wall. This chapter asks an older question that memory never touched: why does a song's data live in one place and the code that plays it in another? A class is where the two finally move in together. Here's the plan. We build a Song and a Playlist from scratch, watch a class stamp out objects that each carry their own data, and pin down the single rule that decides which of two attributes Python finds first. The whole way through, we keep asking the one thing that matters: when you write blinding.play(), where does Python go looking, and in what order? By the end you'll have taught Python what +, == and len() mean on objects you designed. So Blinding Lights (200s) added to Titanium (245s) returns a 445-second playlist that runs on rules you wrote — no magic anywhere, just a lookup you can trace by hand.

01Data and behaviour, finally in one place

Let's start with the crack we've been stepping over for nine chapters. You can describe a song two ways, and they never quite meet. Its data lives in a dict — {"title": "Blinding Lights", "artist": "The Weeknd", "seconds": 200} (chapter 7). Its behaviour lives somewhere else entirely, in a free-standing function that plays it (chapter 9). The two travel apart, and that gap is the quiet flaw. Every function has to be handed the right dict, by hand, every single time, and nothing on Earth stops you handing it the wrong one. Slip a pizza-order dict into your play-song function and Python doesn't so much as flinch. It runs happily along until it reaches for a "title" that was never there and dies mid-show with a KeyError. Keeping the pair together was your job, and that kind of discipline is exactly the stuff bugs are made of.

Now watch the dict try to defend itself. It can't. To Python a song-dict and a pizza-dict are the very same type — both are merely dict — so type(order) cannot tell one from the other at all. There's no seam between them, no stamp that says this one is a song. What you're missing isn't more data. It's a kind.

A class ends the separation. You write the blueprint once — class Song — describing what every song has and what every song can do. Then you stamp concrete objects out of it, each with its own data poured in. One blueprint can build a thousand objects, the way one architect's drawing builds a whole street of houses. And the behaviour comes welded on. To play a song you no longer go hunting for the right function and feed it the right dict. You just ask the object itself, blinding.play(), and it already knows everything it needs to know about itself.

Here's the part that should steady you: you have not left the memory model. This is chapter 3's picture again, unchanged. Each object is a box on the heap, and blinding is just a name holding a reference to it. id(blinding) still returns its address, two objects still carry two different ids, and aliasing still bites: point a second name at the same object and both names see every change. You didn't switch to some alien paradigm. You learned to design your own shape of box for the heap you already understood.

In code it's almost anticlimactic — the whole idea fits in a dozen lines. The blueprint is the class block, and each Song(…) call stamps out one object:

class Song:                                # the blueprint — written once
    def __init__(self, title, artist, seconds):
        self.title   = title                # store each value ON this object
        self.artist  = artist               # (self = the object being built —
        self.seconds = seconds              #  unpacked in full next section)

    def play(self):                        # behaviour now lives WITH the data
        return f"Playing {self.title} by {self.artist}"

blinding = Song("Blinding Lights", "The Weeknd", 200)   # object no. 1
titanium = Song("Titanium", "David Guetta", 245)        # object no. 2

print(blinding.play())          # Playing Blinding Lights by The Weeknd
print(type(blinding).__name__)   # Song  — its own kind, not just 'dict'

Run it and Python confirms the new shape. blinding.play() prints its line without ever being handed a dict, and type(blinding) answers Song — its own kind at last, not one more anonymous dict. The two objects, blinding and titanium, keep their own data cleanly apart: nudge blinding.seconds and titanium.seconds doesn't so much as twitch.

You wrote self three times inside __init__ and never once passed it — yet blinding.play() somehow knows it is Blinding Lights and not Titanium. self isn't magic. It's the instance, quietly handed in. →

02self is not magic — it's the instance

Two questions hide inside one innocent line, Song("Blinding Lights", "The Weeknd", 200). The first is what actually runs? Calling a class isn't like calling a function that returns a value you cooked up by hand. Python does two things, in order. First it builds a blank Song object on the heap — an empty little record with no title, no artist, no length yet. Then it automatically calls that class's __init__ method, the initializer, to fill the blank in. You never call __init__ yourself. Naming the class and opening a parenthesis is the whole ritual, and Python supplies the rest.

The second question is the one everyone trips on: what is self? Count the parameters in the definition. def __init__(self, title, artist, seconds) names four of them, yet you handed the call only three arguments. Where did the fourth come from? It came from Python. The extra parameter, self, is the brand-new blank object itself, delivered to __init__ as the very first argument so the initializer has something to fill. That's why self.title = title reads, quite literally, as: on this particular object, make an attribute named title and set it. And because every call to Song(…) builds a different blank object, every call hands __init__ a different self. That is the entire reason your blinding and your titanium can hold different titles even though they ran the exact same three lines of code.

Now the second half of the section, the part that dissolves the last of the mystery. A method is nothing exotic. It's an ordinary function — the same kind you met back in chapter 9 — that happens to live inside a class and to take the instance as its first parameter. When you write blinding.play(), the dot is pure sugar (we'll refine that word in a moment). Python quietly rewrites it into Song.play(blinding). It looks up play on the class, then ships whatever sits to the left of the dot in as the first argument, self. That's the whole trick. The object doesn't "contain" the method and doesn't "run" it. It just becomes the first thing passed to a function that has always lived on the class. One rewrite rule, zero magic.

class Song:
    def __init__(self, title, artist, seconds):   # 4 parameters...
        self.title = title       # ...but the call passes 3 — Python supplies self
        self.artist = artist
        self.seconds = seconds
    def play(self):
        return f"▶ {self.title} — {self.artist} — {self.seconds} s"

blinding = Song("Blinding Lights", "The Weeknd", 200)   # self = the new object

blinding.play()          # what you write
Song.play(blinding)      # what Python actually runs — identical result

blinding.play            # no () → the method object itself (ch 9)
blinding.play()          # the () are what make it run

Two homes, one search. Every dotted name — blinding.title, blinding.play — sends Python down a single, fixed lookup path that checks the instance first and the class second. Learn that one rule and attribute access never surprises you again. →

03Two kinds of attribute, one lookup rule

Every time you wrote self.title = ... inside __init__, you dropped a value into one object's own private drawer — a little dict Python keeps on each instance, its __dict__. Those are instance attributes: one fresh set per object, exactly right for the data that differs song to song. But now picture a value that is the same for every song in the library — the station stamp "iolinked FM", identical on all ten thousand of them. Store it as an instance attribute and you pay for ten thousand identical copies on the heap, and renaming the station means rewriting every one. That is pure waste, and it points straight at a need: one value that lives in a single place yet every instance can read. Write a name straight in the class body — platform = "iolinked FM" below — and you get exactly that. It is stored once, on the class object itself, and seen by every instance through the one copy. That's a class attribute — one shelf shared by the whole warehouse. (Note the deliberately stripped-down Song here: two fields, title and seconds, no artist — a small drawer so the lookup rule stays the star, and it behaves identically with three. Build blinding = Song("Blinding Lights", 200) and blinding.__dict__ holds exactly {'title': 'Blinding Lights', 'seconds': 200}.)

So when you read blinding.platform, Python doesn't guess and it doesn't search everywhere. It runs one fixed rule, the same one every single time: (1) look in the instance's own __dict__ — nothing there; (2) miss, so climb to the class — found. First hit wins, lookup stops. That two-step is the entire machinery of the dot. Learn it once and attribute access never surprises you again.

class Song:
    platform = "iolinked FM"        # class attribute — one copy, on the class
    def __init__(self, title, seconds):
        self.title = title          # instance attributes — one set per object
        self.seconds = seconds

blinding = Song("Blinding Lights", 200)
titanium = Song("Titanium", 245)

print(blinding.platform)            # iolinked FM   — missed the instance, found the class
blinding.platform = "offline mix"   # plants an INSTANCE attribute
print(blinding.platform)            # offline mix   — its own copy now shadows the class
print(titanium.platform)            # iolinked FM   — the class copy never moved

That same rule explains the trickiest move in the whole topic — shadowing. When you ran blinding.platform = "offline mix", Python did not reach up and rewrite the class's copy. Assigning through an instance can only ever write into that instance's drawer, so it dropped a brand-new platform key into blinding.__dict__. Now step 1 finds it and the climb never happens, so blinding sees "offline mix". Meanwhile titanium, whose drawer has no such key, still climbs and reads "iolinked FM", and Song.platform itself never budged. Only an assignment to the class, Song.platform = ..., moves the shared copy. Peel the shadow off with del blinding.platform and the class value shines through again, untouched the whole time.

The memory bill falls straight out of this. Make a thousand songs and you get a thousand tiny per-instance dicts of data — each just a handful of keys — plus one class object carrying the shared attributes and every method exactly once. The behaviour doesn't multiply; only the data does. (If even those little dicts feel too heavy at scale, __slots__ deletes them and packs the fields into a fixed row, as in chapter 11.)

class Playlist:
    songs = []              # ONE list, built once, living on the class

a = Playlist()
b = Playlist()
a.songs.append("Blinding Lights")
print(b.songs)              # ['Blinding Lights']  — b never touched it, yet there it is
print(a.songs is b.songs)   # True  — one shared list, not two

# the fix: give every object its own list in __init__
class Playlist:
    def __init__(self):
        self.songs = []    # a fresh list per object — no sharing

One class, its behaviour shared by every instance that climbs to it. But what happens when you need a blueprint that's almost a Song — every attribute and method identical, save one twist? You won't copy the whole class. You'll borrow it, add a rung to that ladder, and change exactly one thing. →

04Inheritance: borrow a class, change one thing

A live recording is still a song. Same title, same artist, same running time, the same idea of pressing play — plus one new thing: a venue. So how do you build a LiveSong class? The lazy answer is to copy the whole Song class and paste in a venue. You'd regret it twice. Every bug you ever wrote in Song now lives in two places, and the day you fix one you'll forget the other. There is a better move, and it's the backbone of every object system ever built: inheritance — say what's new, borrow the rest.

One line does it: class LiveSong(Song):. That parenthesis names Song the parent (or base class) and makes LiveSong its child (or subclass). The child starts life with everything the parent defines — even __init__ itself, if the child never writes its own. From there the child can do exactly three things. It can add something the parent lacks (the venue), override a method by defining its own version (a different play()), or extend one with super().__init__(title, artist, seconds) — which means "run Song's initializer on this same self first, then keep going with my own lines." Add, override, extend. That's the whole toolkit.

So when you write gig.play(), where does Python actually look? It walks that path — the MRO, the method resolution order: a fixed list of classes searched strictly in sequence, LiveSong, then Song, then object. The first class that defines play wins, and the search stops dead. That is the entire meaning of "override": the child's play is found before the parent's, so the parent's never runs. Ask for a name the child doesn't have — gig.encore() — and the search falls straight through to Song. And because a LiveSong genuinely is a Song, the built-in test isinstance(gig, Song) — "was this object stamped from this class, or from any ancestor of it?" — comes back True.

class Song:                                  # the parent — every song can play
    def __init__(self, title, artist, seconds):
        self.title, self.artist = title, artist
        self.seconds = seconds
    def play(self):
        return f"Now playing {self.title} by {self.artist}"
    def encore(self):                        # only Song defines this one
        return f"One more time: {self.title}!"

class LiveSong(Song):                        # a Song, plus a venue
    def __init__(self, title, artist, seconds, venue):
        super().__init__(title, artist, seconds)  # run Song's setup first
        self.venue = venue                        # then add the new bit
    def play(self):                          # override the parent's play
        return f"Playing {self.title} live at {self.venue}"

studio = Song("Blinding Lights", "The Weeknd", 200)
gig    = LiveSong("Blinding Lights", "The Weeknd", 210, "Coachella")

print(gig.play())              # Playing Blinding Lights live at Coachella
print(gig.encore())            # One more time: Blinding Lights!   (inherited)
print(gig.seconds)             # 210 — set by Song.__init__, via super()
print(isinstance(gig, Song))     # True — a LiveSong IS a Song
print([c.__name__ for c in LiveSong.__mro__])   # ['LiveSong', 'Song', 'object']

Notice the studio cut is the canonical 200 s you've carried since chapter 0. This live take runs a touch longer at 210 s — same song, different recording, and the venue is the only genuinely new field. Everything else was borrowed.

gig = LiveSong("Blinding Lights", "The Weeknd", 210, "Coachella")
Song.remix = lambda self: f"remix of {self.title}"   # add to the PARENT, now
print(gig.remix())        # remix of Blinding Lights — the child sees it instantly

class Track:
    def __init__(self): print("Track")
class Recorded(Track):
    def __init__(self): print("Recorded"); super().__init__()
class Timed(Track):
    def __init__(self): print("Timed"); super().__init__()
class LiveCut(Recorded, Timed):
    def __init__(self): print("LiveCut"); super().__init__()

print([c.__name__ for c in LiveCut.__mro__])
# ['LiveCut', 'Recorded', 'Timed', 'Track', 'object']
LiveCut()   # prints LiveCut, Recorded, Timed, Track — and Track just ONCE

That question in the curio — one line, several possible methods, the object itself deciding which runs — has a name, and it's the last big idea of this chapter. Next: how a bare loop over a pile of mismatched objects gets each one to do the right thing, with not a single if-check in sight.

05Polymorphism: the object picks the method

Here is the payoff the whole chapter has been climbing toward. One line — track.play() — is the entire call site, and yet it produces three different results, one per song, with not a single if in sight. That is polymorphism (Greek for "many shapes"): the same call, answered differently depending on what object is standing left of the dot. The machinery underneath is dynamic dispatch. It's dynamic because it happens at run time, not when you wrote the line, and dispatch because Python has to route the call to exactly one piece of code. When the interpreter reaches track.play(), it looks at the actual object track is bound to at that instant, starts the method hunt at that object's own class, and walks up the MRO — the method-resolution order you met a section ago — until it finds a play. The caller never chooses which method runs. The object does.

We built Song and its subclass LiveSong earlier in the chapter, where LiveSong overrides play() to announce a venue. Now add one more, Remix, and watch it closely. It defines no play() of its own; it only rewrites the title in its __init__. Then we line all three up and call the same method on each:

class Remix(Song):                      # inherits play() untouched — defines none of its own
    def __init__(self, title, artist, seconds, remixer):
        super().__init__(f"{title} ({remixer} Remix)", artist, seconds)

playlist = [
    Song("Blinding Lights", "The Weeknd", 200),              # studio original
    LiveSong("Titanium", "David Guetta", 245, "Tomorrowland"),
    Remix("Blinding Lights", "The Weeknd", 200, "Kaskade"),
]

for track in playlist:
    print(track.play())        # one line — three behaviours
# Playing Blinding Lights by The Weeknd
# Playing Titanium live at Tomorrowland
# Playing Blinding Lights (Kaskade Remix) by The Weeknd

That third column is the one to sit with. The Remix has no play(), so the search climbs its MRO — Remix → Song → object — and stops at Song. But here's the sleight of hand. The MRO only decided which function to run; it never touched self. Song's code executes, yet self is still the Remix, so self.title is the remixed title the Remix wrote in its own __init__. Method borrowed from the parent; data owned by the child. Drive the slider and watch the search start in a different place, and, for the Remix, watch it climb.

And notice what the loop never does: it never asks track what type it is. It only asks it to .play(). Anything that answers that request qualifies, related by inheritance or not. This is duck typing: if it walks like a duck and quacks like a duck, treat it as a duck. A Podcast class that shares no ancestry with Song at all, but happens to define its own play(), drops into the playlist and the loop is none the wiser.

Duck typing is a convention, though. Nothing stops you from dropping in a track that forgot to define play(), and you'd only find out when the loop crashes on that item, halfway through the playlist. Want the promise enforced up front? An abstract base class declares a required method with no body, and Python then refuses to build any object whose class hasn't supplied one. That brings one new scrap of syntax below. A line beginning with @ is a decorator, and it is not vague at all — it's a single rewrite rule, in the same spirit as class unfolding to a type() call. @d written above def f means exactly f = d(f): define the function, hand it to d, and rebind the name to whatever d returns. So @abstractmethod over def play runs play = abstractmethod(play), and all abstractmethod does is set one flag on the function object, play.__isabstractmethod__ = True. The enforcement lives in ABC. It installs a metaclass (the class-builder type from this chapter's opener, doing extra work at build time — you never write one yourself) that scans for any still-flagged method and raises TypeError the instant you try to instantiate. A tag, yes, but a tag that reduces to one plain function call and one boolean, nothing hand-wavy.

from abc import ABC, abstractmethod

class Playable(ABC):          # ABC supplies the enforcement machinery
    @abstractmethod
    def play(self): ...       # a promise with no body

Playable()   # TypeError: Can't instantiate abstract class Playable
             #            without an implementation for abstract method 'play'
             # a subclass that forgets play() fails the very same way —
             # at build time, not as a surprise crash mid-playlist

The object decides what .play() means. But could it also decide what +, ==, and len() mean — and hide its own insides while it's at it? Next: dunders, @property, and the privacy that isn't. →

06Dunders, @property, and the privacy that isn't

Here's a secret you've kept from yourself all course. Every time you wrote len(playlist) or a + b or print(song), you were calling a method — you just never saw its name. Python keeps a set of reserved method names wrapped in double underscores — dunders, for double underscore — and each one is a hook into a piece of the language's own grammar. Define the hook on your class and your object plugs straight into the syntax everyone else's objects use. len(x) quietly runs x.__len__(). a + b runs a.__add__(b). print(x) asks x.__str__() for a friendly string and, if you never wrote one, falls back to x.__repr__().

Skip those hooks and your objects stay second-class. Print a bare Song with no __repr__ and Python shrugs out something like <__main__.Song object at 0x1d8…> — the class name, then the object's address in memory. That hex number is id(song) from chapter 3, written in base 16: honest, and useless to you. But define the hooks and the class comes alive. len(party) just works, + merges two playlists (that's operator overloading), and == starts comparing what the songs are instead of falling back to whether they're the very same object, chapter 4's is. You stop describing your object to Python and start teaching Python to speak your object. And + is where that lesson turns literal. On a Playlist it merges — two song lists glued end to end — but drop below the playlist to the samples those songs are actually built from, and the very same + is forced into real arithmetic on the metal.

class Song:
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds
    def __repr__(self):                     # what the shell and containers show
        return f"Song({self.title!r}, {self.artist!r}, {self.seconds})"
    def __eq__(self, other):                # what == means for two Songs
        if not isinstance(other, Song):
            return NotImplemented          # "not mine" — let the other side try
        return (self.title, self.artist) == (other.title, other.artist)

class Playlist:
    def __init__(self, songs):
        self.songs = list(songs)            # our own copy — no aliasing (ch 3)
    def __len__(self):                     # len(pl)
        return len(self.songs)
    def __add__(self, other):              # pl + other  → a merged Playlist
        return Playlist(self.songs + other.songs)
    def __getitem__(self, i):             # pl[i] — and, for free, looping
        return self.songs[i]

night = Playlist([Song("Blinding Lights", "The Weeknd", 200)])
gym   = Playlist([Song("Titanium", "David Guetta ft. Sia", 245)])

print(len(night + gym))       # 2   — __add__ builds it, __len__ counts it
print((night + gym)[1])       # Song('Titanium', 'David Guetta ft. Sia', 245)
for song in night + gym:      # __getitem__ drives the loop — no __iter__ needed
    print(song.title)          # Blinding Lights  /  Titanium
print(Song("Blinding Lights", "The Weeknd", 200)
      == Song("Blinding Lights", "The Weeknd", 200))   # True — value, not identity

Now zoom that same Playlist down one floor. A Song carries a seconds — 200 for "Blinding Lights" — but that duration is human metadata, a label stapled to the object. It is not the music. The music is a waveform: a long run of numbers, each one the position of the speaker cone at a single instant. In mono 16-bit PCM every sample is a signed 16-bit integer — -32768..32767, with 0 the cone at rest — and the array('h') type packs them two bytes apiece. At 44100 samples a second, those 200 seconds come to about 8.8 million samples, and array('h', [0, 12000, 24000, 18000, -6000, -22000, -14000, 3000]) is one eight-sample sliver of them. Those bytes are the metal the playlist has been standing on all along. A sample is an object like any other, so it too can own an __add__.

from array import array

class Sample:                              # one 16-bit PCM sample = a cone position
    __slots__ = ("v",)                     # ch 11: no per-sample __dict__
    LO, HI = -32768, 32767              # the hard rails a 16-bit sample can reach
    def __init__(self, v):
        self.v = v
    def __add__(self, other):              # a + b  →  mix the two cones
        mixed = self.v + other.v            # Python int: grows freely, never overflows
        if   mixed > Sample.HI: mixed = Sample.HI   # but the metal saturates:
        elif mixed < Sample.LO: mixed = Sample.LO   # clip to the rail, don't wrap
        return Sample(mixed)
    def __repr__(self):
        return f"Sample({self.v})"

track = array('h', [0, 12000, 24000, 18000, -6000, -22000, -14000, 3000])
print(Sample(track[2]) + Sample(track[3]))   # 24000 + 18000 = 42000 → Sample(32767), clipped
print(Sample(track[0]) + Sample(track[4]))   # 0 + (-6000) = Sample(-6000), safely inside the rails

Two refinements turn a workable class into a graceful one. The first is @property, and by the rewrite rule you just met it is plain. @property over def minutes runs minutes = property(minutes), storing a property object on the class where the method's name used to be. That property object is a data descriptor: it carries a __get__ (and, once you add a setter, a __set__). That one fact is the whole trick. When you write bl.minutes, section 03's lookup runs, but a data descriptor on the class outranks the instance's own __dict__ (the single refinement to the instance-first rule). Python finds minutes on the class and calls type(bl).__dict__['minutes'].__get__(bl, Song), which runs your getter and hands back its value, recomputed fresh on every access. So minutes is derived from _seconds and can never drift out of sync with it. It was never stored; it is answered on demand. Add a matching @minutes.setter (again just minutes = minutes.setter(func)) and the descriptor's __set__ fires on bl.minutes = 5 — the perfect place to reject a negative running time before it can corrupt your data.

The second refinement is that leading underscore in _seconds. That single character is Python's whole notion of encapsulation: a naming convention that whispers "internal — reach me through the property, not directly." Nothing stops you from touching bl._seconds. The underscore is a handshake between programmers, enforced by politeness, not by the interpreter. That sets up the single biggest misconception in the language, because a great many people believe a second underscore upgrades that handshake into a lock. It does not.

class Song:
    def __init__(self, title, seconds):
        self.title = title
        self._seconds = seconds        # _ = "internal"; go through the property

    @property
    def minutes(self):                 # a method that READS like an attribute
        return self._seconds / 60

    @minutes.setter
    def minutes(self, value):          # runs on:  bl.minutes = ...
        if value < 0:
            raise ValueError("a song can't run negative time")
        self._seconds = value * 60

bl = Song("Blinding Lights", 200)
print(bl.minutes)      # 3.3333333333333335  — no parentheses, computed now
bl.minutes = 5         # goes through the setter, which validates first
print(bl._seconds)     # 300  — the setter wrote it back in seconds

Now the lock that isn't. Try to make an attribute truly private and you meet name mangling — the trick nearly everyone misreads as access control. Give an attribute two leading underscores inside a class, and the compiler quietly rewrites the name. Inside class BankAccount, self.__balance is stored under the mangled name _BankAccount__balance. The double underscore was never a keep-out sign. It's a rename, invented so a subclass can't accidentally clobber a base class's __balance with one of its own. Step through what that actually does when someone pokes at it from outside:

class BankAccount:
    def __init__(self):
        self.__balance = 100            # actually stored as _BankAccount__balance

acct = BankAccount()
# acct.__balance                       → AttributeError: no such name exists
print(acct._BankAccount__balance)     # 100   — the mangled name is the real one
acct.__balance = -100                  # NO error — creates a brand-new attribute
print(acct._BankAccount__balance)     # 100   — the real balance never moved
print(acct.__balance)                 # -100  — the impostor you just created

Your Playlist now speaks the whole language — +, len(), [ ], ==, sorting, printing. But hand one of its methods a value it never expected and the program still dies mid-song, spilling a traceback down the screen. Next chapter, errors & robustness: how Python raises the alarm when something breaks, and how to catch a failure in flight instead of letting it take the whole playlist down with it. →