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. In this one we ask the 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, then watch a class stamp out objects that each carry their own data. We pin down the single rule that decides which of two attributes Python finds first. And the whole way through we keep asking the one thing that actually 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. The pairing was your discipline to keep, and 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) can no more tell a plate of food from a Weeknd single than a cardboard box can tell socks from a violin. 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; 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, since 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. Two objects, blinding and titanium, keep their own data cleanly apart. Nudge blinding.seconds and titanium.seconds doesn't so much as twitch.

class Song:
    platform = "iolinked FM"     # written in the class body

a, b = Song(), Song()
Song.platform = "iolinked AM"    # edit the CLASS -- after both objects exist
print(a.platform, b.platform)
print(a.__dict__)

iolinked AM iolinked AM
{}

you type
class Song:                                       # 1 - the class statement mints a new kind
    platform = "iolinked FM"                      # 2 - class attribute: one copy, shared

    def __init__(self, title, artist, seconds):   # 3 - the initializer, called for you
        self.title = title                        # 4 - instance attributes: one set per object
        self.artist = artist
        self.seconds = seconds

    def play(self):                               # 5 - a method: a function that takes the instance
        return f"Playing {self.title} by {self.artist}"

blinding = Song("Blinding Lights", "The Weeknd", 200)   # 6 - instantiation

print(blinding.play())
print(blinding.title, "|", blinding.platform)
print(type(blinding).__name__, isinstance(blinding, Song))
print(blinding.__dict__)
print(sorted(k for k in Song.__dict__ if not k.startswith("__")))

you see
Playing Blinding Lights by The Weeknd
Blinding Lights | iolinked FM
Song True
{'title': 'Blinding Lights', 'artist': 'The Weeknd', 'seconds': 200}
['platform', 'play']

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. →

# song_grows.py -- one class, four stages. Nothing is thrown away; each stage adds one part.

# ---- stage 1: the bare class. A new kind, and nothing else. ----
class Song:
    pass

s1 = Song()
print("stage 1:", type(s1).__name__, "|", repr(s1).split(" 0x")[0] + " 0x...>")

# ---- stage 2: __init__ pours the data in ----
class Song:
    def __init__(self, title, artist, seconds):
        self.title = title
        self.artist = artist
        self.seconds = seconds

s2 = Song("Blinding Lights", "The Weeknd", 200)
print("stage 2:", s2.title, "|", s2.__dict__)

# ---- stage 3: a method -- behaviour welded to the data ----
class Song:
    def __init__(self, title, artist, seconds):
        self.title = title
        self.artist = artist
        self.seconds = seconds

    def play(self):
        return f"Playing {self.title} by {self.artist}"

s3 = Song("Blinding Lights", "The Weeknd", 200)
print("stage 3:", s3.play(), "|", Song.play(s3))

# ---- stage 4: __repr__ -- the object learns to say what it is ----
class Song:
    def __init__(self, title, artist, seconds):
        self.title = title
        self.artist = artist
        self.seconds = seconds

    def play(self):
        return f"Playing {self.title} by {self.artist}"

    def __repr__(self):
        return f"Song({self.title!r}, {self.artist!r}, {self.seconds})"

library = [Song("Blinding Lights", "The Weeknd", 200),
           Song("Titanium", "David Guetta", 245)]
print("stage 4:", library[0])
print("stage 4:", library)
print("stage 4:", sum(s.seconds for s in library), "seconds of music")

stage 1: Song | <__main__.Song object at 0x...>
stage 2: Blinding Lights | {'title': 'Blinding Lights', 'artist': 'The Weeknd', 'seconds': 200}
stage 3: Playing Blinding Lights by The Weeknd | Playing Blinding Lights by The Weeknd
stage 4: Song('Blinding Lights', 'The Weeknd', 200)
stage 4: [Song('Blinding Lights', 'The Weeknd', 200), Song('Titanium', 'David Guetta', 245)]
stage 4: 445 seconds of music

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. Python delivers it 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 every call to Song(…) builds a different blank object. So every call hands __init__ a different self. That's 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, and 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 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.

you type
class Song:
    def __init__(self, title, seconds):
        self.title = title
        self.seconds = seconds

    def play(self):
        return f"Playing {self.title}"

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

print(blinding.play())                 # the dot form
print(Song.play(blinding))             # the honest form -- identical work
print(blinding.play() == Song.play(blinding))

print(type(Song.play).__name__, type(blinding.play).__name__)
print(blinding.play.__func__ is Song.play)
print(blinding.play.__self__ is blinding)
print(Song.play(titanium))             # self is only ever "whatever came first"

you see
Playing Blinding Lights
Playing Blinding Lights
True
function method
True
True
Playing Titanium

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. →

class Track:
    """One track in the iolinked library."""

    def __init__(self, title, artist, seconds, explicit=False):
        self.title = title
        self.artist = artist
        self.seconds = seconds
        self.explicit = explicit

    def label(self):
        minutes, secs = divmod(self.seconds, 60)
        mark = " [E]" if self.explicit else ""
        return f"{self.title} - {self.artist} - {minutes}:{secs:02d}{mark}"

    def __repr__(self):
        return f"Track({self.title!r}, {self.artist!r}, {self.seconds})"

bad_guy = Track("bad guy", "Billie Eilish", 194, explicit=True)
levels = Track("Levels", "Avicii", 203)

print(bad_guy.label())
print(levels.label())
print(bad_guy)
print([bad_guy, levels])
print(Track.label(levels))
print(bad_guy.__dict__)
print(sorted(k for k in Track.__dict__ if not k.startswith("_")))

# ------------- what it prints -------------
bad guy - Billie Eilish - 3:14 [E]
Levels - Avicii - 3:23
Track('bad guy', 'Billie Eilish', 194)
[Track('bad guy', 'Billie Eilish', 194), Track('Levels', 'Avicii', 203)]
Levels - Avicii - 3:23
{'title': 'bad guy', 'artist': 'Billie Eilish', 'seconds': 194, 'explicit': True}
['label']

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. That drawer is 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. Renaming the station then 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. It's 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) That's a 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: 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.

you type
class Song:
    platform = "iolinked FM"          # one shared value, stored on the class
    count = 0                         # one shared tally

    def __init__(self, title):
        self.title = title            # one per object
        Song.count += 1               # name the CLASS to move the shared copy

blinding = Song("Blinding Lights")
titanium = Song("Titanium")

print(Song.count, blinding.count, titanium.count)
blinding.platform = "offline mix"     # plants an INSTANCE attribute
print(blinding.platform, "|", titanium.platform, "|", Song.platform)
print(blinding.__dict__)
del blinding.platform                 # peel the shadow off
print(blinding.platform)

class Broken:
    count = 0
    def __init__(self):
        self.count += 1               # reads the class, writes the instance

b1, b2 = Broken(), Broken()
print(Broken.count, b1.count, b2.count)

you see
2 2 2
offline mix | iolinked FM | iolinked FM
{'title': 'Blinding Lights', 'platform': 'offline mix'}
iolinked FM
0 1 1

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. On top of that sits 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 — chapter 11.)

Traceback (most recent call last):
  File "song.py", line 6, in <module>
    blinding = Song("Blinding Lights", 200)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Song() takes no arguments

Traceback (most recent call last):
  File "song.py", line 6, in <module>
    blinding = Song("Blinding Lights", "The Weeknd", 200)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Song.__init__() takes 3 positional arguments but 4 were given

Traceback (most recent call last):
  File "song.py", line 8, in <module>
    print(Song.title)
          ^^^^^^^^^^
AttributeError: type object 'Song' has no attribute 'title'

# bank_account.py -- from Ajai's OOP notes, cleaned. The balance is the object's business.

class BankAccount:
    bank = "iolinked Savings"              # class attribute: one copy for every account
    opened = 0                             # a shared tally of accounts ever opened

    def __init__(self, owner, initial_balance=0):
        if initial_balance < 0:
            raise ValueError("an account cannot open in the red")
        self.owner = owner                 # instance attribute: one per account
        self._balance = initial_balance    # one underscore: internal, please knock
        BankAccount.opened += 1            # name the CLASS to move the shared tally

    def deposit(self, amount):
        if amount <= 0:
            return False                   # the guard the first draft was missing
        self._balance += amount
        return True

    def withdraw(self, amount):
        if amount <= 0 or amount > self._balance:
            return False                   # refuse; never let the balance go negative
        self._balance -= amount
        return True

    def get_balance(self):
        return self._balance


acct = BankAccount("Ajai", 100)
print(acct.bank, "|", acct.owner, "|", acct.get_balance())

print("deposit   50 ->", acct.deposit(50), "| balance", acct.get_balance())
print("withdraw  75 ->", acct.withdraw(75), "| balance", acct.get_balance())
print("withdraw 500 ->", acct.withdraw(500), "| balance", acct.get_balance())
print("deposit  -20 ->", acct.deposit(-20), "| balance", acct.get_balance())

second = BankAccount("Anu", 20)
second.deposit(5)
print(second.owner, second.get_balance(), "|", acct.owner, acct.get_balance())
print("accounts opened:", BankAccount.opened, "| shared bank:", second.bank)

try:
    BankAccount("Ghost", -5)
except ValueError as e:
    print("ValueError:", e)

iolinked Savings | Ajai | 100
deposit   50 -> True | balance 150
withdraw  75 -> True | balance 75
withdraw 500 -> False | balance 75
deposit  -20 -> False | balance 75
Anu 25 | Ajai 75
accounts opened: 2 | shared bank: iolinked Savings
ValueError: an account cannot open in the red

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. →

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

    def add(self, title):
        self.songs.append(title)  # climbs to the class, then mutates in place

night = Playlist()
gym = Playlist()
night.add("Blinding Lights")
gym.add("Titanium")

print("night:", night.songs)
print("gym  :", gym.songs)
print("same list?", night.songs is gym.songs)
print("on the class:", Playlist.songs)
print("night's own drawer:", night.__dict__)

# the fix: the list is born in __init__, so every object gets its own
class Playlist:
    def __init__(self):
        self.songs = []

    def add(self, title):
        self.songs.append(title)

night = Playlist()
gym = Playlist()
night.add("Blinding Lights")
gym.add("Titanium")

print()
print("night:", night.songs)
print("gym  :", gym.songs)
print("same list?", night.songs is gym.songs)
print("on the class:", "songs" in Playlist.__dict__)
print("night's own drawer:", night.__dict__)

# ------------- what it prints -------------
night: ['Blinding Lights', 'Titanium']
gym  : ['Blinding Lights', 'Titanium']
same list? True
on the class: ['Blinding Lights', 'Titanium']
night's own drawer: {}

night: ['Blinding Lights']
gym  : ['Titanium']
same list? False
on the class: False
night's own drawer: {'songs': ['Blinding Lights']}

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, which means say what's new and 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). It can override a method by defining its own version (a different play()). Or it can 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.

you type
class Song:
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

    def play(self):
        return f"Playing {self.title} by {self.artist}"

    def encore(self):
        return f"One more time: {self.title}!"

class Remix(Song):                                   # say what is new, borrow the rest
    def __init__(self, title, artist, seconds, remixer):
        super().__init__(title, artist, seconds)     # the parent's setup, same self
        self.remixer = remixer                       # then the new field

    def play(self):                                  # override: same name, new body
        return f"Playing {self.title} ({self.remixer} Remix)"

blinding = Song("Blinding Lights", "The Weeknd", 200)
kaskade = Remix("Blinding Lights", "The Weeknd", 200, "Kaskade")

print(blinding.play())
print(kaskade.play())
print(kaskade.encore())              # inherited -- Remix never wrote it
print(kaskade.artist)                # set by Song.__init__, reached through super()
print(isinstance(kaskade, Remix), isinstance(kaskade, Song), type(kaskade) is Song)
print(issubclass(Remix, Song), issubclass(Song, Remix))
print([c.__name__ for c in Remix.__mro__])

you see
Playing Blinding Lights by The Weeknd
Playing Blinding Lights (Kaskade Remix)
One more time: Blinding Lights!
The Weeknd
True True False
True False
['Remix', 'Song', 'object']

So when you write gig.play(), where does Python actually look? It walks that path, the MRO or 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.

# live_set.py -- one parent, three children, and the only three moves: add, override, extend.

class Song:
    def __init__(self, title, artist, seconds):
        self.title = title
        self.artist = artist
        self.seconds = seconds

    def play(self):
        return f"Playing {self.title} by {self.artist}"

    def encore(self):
        return f"One more time: {self.title}!"

    def __repr__(self):
        return f"{type(self).__name__}({self.title!r}, {self.seconds})"


class LiveSong(Song):                          # EXTEND: the parent's setup, plus a venue
    def __init__(self, title, artist, seconds, venue):
        super().__init__(title, artist, seconds)
        self.venue = venue

    def play(self):                            # OVERRIDE: same name, new body
        return f"Playing {self.title} live at {self.venue}"


class Remix(Song):                             # ADD: a new field, and no play() at all
    def __init__(self, title, artist, seconds, remixer):
        super().__init__(f"{title} ({remixer} Remix)", artist, seconds)
        self.remixer = remixer


class Careless(Song):                          # the classic mistake, made on purpose
    def __init__(self, title):
        self.title = title                     # no super() -- artist is never set


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

for track in setlist:
    print(f"{type(track).__name__:9} {track.play()}")

print()
print(setlist)
print("encore, inherited by all three :", setlist[1].encore())
print("seconds, set through super()   :", setlist[1].seconds)
print("isinstance / issubclass        :", isinstance(setlist[1], Song), issubclass(Remix, Song))
print("LiveSong MRO                   :", [c.__name__ for c in LiveSong.__mro__])

print()
broken = Careless("Levels")
try:
    print(broken.play())
except AttributeError as e:
    print("AttributeError:", e)

Song      Playing Blinding Lights by The Weeknd
LiveSong  Playing Titanium live at Tomorrowland
Remix     Playing Blinding Lights (Kaskade Remix) by The Weeknd

[Song('Blinding Lights', 200), LiveSong('Titanium', 245), Remix('Blinding Lights (Kaskade Remix)', 200)]
encore, inherited by all three : One more time: Titanium!
seconds, set through super()   : 245
isinstance / issubclass        : True True
LiveSong MRO                   : ['LiveSong', 'Song', 'object']

AttributeError: 'Careless' object has no attribute 'artist'

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.

you type
class Song:
    def __init__(self, title, seconds):
        self.title, self.seconds = title, seconds

class Playlist:                          # HAS-A: a playlist holds songs
    def __init__(self, name):
        self.name = name
        self.songs = []                  # the parts live in a field

    def add(self, song):
        self.songs.append(song)
        return self

    def total_seconds(self):
        return sum(s.seconds for s in self.songs)

class LiveSong(Song):                    # IS-A: a live cut is a song, with a venue
    def __init__(self, title, seconds, venue):
        super().__init__(title, seconds)
        self.venue = venue

night = Playlist("Night drive")
night.add(Song("Blinding Lights", 200)).add(LiveSong("Titanium", 245, "Tomorrowland"))
print(night.name, len(night.songs), night.total_seconds())
print(isinstance(night, Song), isinstance(night.songs[1], Song))

class BadPlaylist(Song):                 # the wrong tree: inheriting what you merely own
    pass

wrong = BadPlaylist("Night drive", 0)
print(wrong.title, wrong.seconds)        # a playlist with a running time of its own?
print(isinstance(wrong, Song))           # True -- and that is exactly the bug

you see
Night drive 2 445
False True
Night drive 0
True

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. 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. It's 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. It 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 — 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.

# four scenarios, and the code that settles each one

class Song:
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

    def play(self):
        return f"Playing {self.title} by {self.artist}"

    def __repr__(self):
        return f"Song({self.title!r})"

# 1 - Album and Song -> HAS-A. An album is not a song; it holds songs.
class Album:
    def __init__(self, title, songs):
        self.title = title
        self.songs = list(songs)

    def total_seconds(self):
        return sum(s.seconds for s in self.songs)

# 2 - AcousticVersion and Song -> IS-A. The same thing, one twist.
class AcousticVersion(Song):
    def play(self):
        return f"Playing {self.title} (acoustic) by {self.artist}"

# 3 - Playlist and list -> HAS-A. Hold a list; do not become one.
class Playlist:
    def __init__(self, name):
        self.name = name
        self.items = []

    def add(self, item):
        self.items.append(item)

    def __len__(self):
        return len(self.items)

# 4 - PodcastEpisode and Song -> NEITHER. No shared ancestor, just the same verb.
class PodcastEpisode:
    def __init__(self, show, host, seconds):
        self.show, self.host, self.seconds = show, host, seconds

    def play(self):
        return f"Streaming {self.show}, hosted by {self.host}"


bl = Song("Blinding Lights", "The Weeknd", 200)
ac = AcousticVersion("Titanium", "David Guetta", 230)
ep = PodcastEpisode("Darknet Diaries", "Jack Rhysider", 3600)

album = Album("After Hours", [bl, ac])
print("1 has-a :", album.title, "|", len(album.songs), "songs |", album.total_seconds(), "s |",
      "isinstance(album, Song) ->", isinstance(album, Song))
print("2 is-a  :", ac.play(), "| isinstance(ac, Song) ->", isinstance(ac, Song))

pl = Playlist("Night drive")
pl.add(bl)
pl.add(ep)
print("3 has-a :", len(pl), "items | isinstance(pl, list) ->", isinstance(pl, list))
print("4 duck  :", [item.play() for item in pl.items])

# ------------- what it prints -------------
1 has-a : After Hours | 2 songs | 430 s | isinstance(album, Song) -> False
2 is-a  : Playing Titanium (acoustic) by David Guetta | isinstance(ac, Song) -> True
3 has-a : 2 items | isinstance(pl, list) -> False
4 duck  : ['Playing Blinding Lights by The Weeknd', 'Streaming Darknet Diaries, hosted by Jack Rhysider']

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. 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). 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. →

you type
class Song:
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

    def play(self):                                  # instance method: self is the object
        return f"Playing {self.title}"

    @classmethod
    def from_string(cls, row):                       # cls is the CLASS itself
        title, artist, seconds = row.split(" - ")
        return cls(title, artist, int(seconds))      # cls(...) builds the right kind

    @staticmethod
    def mmss(seconds):                               # no self, no cls: a plain helper
        minutes, secs = divmod(seconds, 60)
        return f"{minutes}:{secs:02d}"

class Remix(Song):
    pass

blinding = Song.from_string("Blinding Lights - The Weeknd - 200")
kaskade = Remix.from_string("Blinding Lights - The Weeknd - 205")

print(blinding.title, blinding.seconds, Song.mmss(blinding.seconds))
print(type(blinding).__name__, type(kaskade).__name__)     # cls followed the caller
print(Song.mmss(245), blinding.mmss(245))
print(Song.from_string.__self__ is Song, Remix.from_string.__self__ is Remix)
print(type(Song.__dict__["mmss"]).__name__, type(Song.__dict__["from_string"]).__name__)

you see
Blinding Lights 200 3:20
Song Remix
4:05 4:05
True True
staticmethod classmethod

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 but 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.

you type
class Song:                                   # no dunders of its own
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

class Track:                                  # the same data, wired into the language
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

    def __repr__(self):                       # for the programmer: unambiguous
        return f"Track({self.title!r}, {self.artist!r}, {self.seconds})"

    def __str__(self):                        # for the human reading the screen
        return f"{self.title} - {self.artist}"

    def __eq__(self, other):                  # what == means for two Tracks
        if not isinstance(other, Track):
            return NotImplemented             # "not mine" -- let the other side try
        return (self.title, self.artist) == (other.title, other.artist)

class Playlist:
    def __init__(self, tracks):
        self.tracks = list(tracks)

    def __len__(self):                        # len(pl)
        return len(self.tracks)

a = Song("Blinding Lights", "The Weeknd", 200)
b = Song("Blinding Lights", "The Weeknd", 200)
print(a == b, a is b)                         # no __eq__: == falls back to identity

x = Track("Blinding Lights", "The Weeknd", 200)
y = Track("Blinding Lights", "The Weeknd", 200)
print(x == y, x is y)                         # same value, two objects
print(str(x))
print(repr(x))
print(x)                                      # print asks __str__ ...
print([x, y])                                 # ... a container always asks __repr__
print(len(Playlist([x, y])))
print(x == "Blinding Lights")                 # NotImplemented -> Python falls back

you see
False False
True False
Blinding Lights - The Weeknd
Track('Blinding Lights', 'The Weeknd', 200)
Blinding Lights - The Weeknd
[Track('Blinding Lights', 'The Weeknd', 200), Track('Blinding Lights', 'The Weeknd', 200)]
2
False

you type
from dataclasses import dataclass, field

@dataclass
class Song:
    title: str
    artist: str
    seconds: int = 0

@dataclass
class Playlist:
    name: str
    songs: list = field(default_factory=list)   # a FRESH list for every object

a = Song("Blinding Lights", "The Weeknd", 200)
b = Song("Blinding Lights", "The Weeknd", 200)
print(a)                                        # __repr__, written for you
print(a == b, a is b)                           # __eq__, field by field
print(a.title, a.seconds)

night, gym = Playlist("Night"), Playlist("Gym")
night.songs.append(a)
print(len(night.songs), len(gym.songs), night.songs is gym.songs)
print(Playlist("Empty"))

@dataclass(frozen=True, order=True)
class Sample:
    value: int

print(sorted([Sample(3), Sample(-1), Sample(2)]))
try:
    Sample(1).value = 9
except Exception as e:
    print(type(e).__name__ + ":", e)

you see
Song(title='Blinding Lights', artist='The Weeknd', seconds=200)
True False
Blinding Lights 200
1 0 False
Playlist(name='Empty', songs=[])
[Sample(value=-1), Sample(value=2), Sample(value=3)]
FrozenInstanceError: cannot assign to field 'value'

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. The array 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. And a sample is an object like any other, so it too can own an __add__.

you type
class Song:
    def __init__(self, title, seconds):
        self.title, self.seconds = title, seconds

    def __repr__(self):
        return f"Song({self.title!r}, {self.seconds})"

    def __lt__(self, other):                  # one method, and sorted() starts working
        if not isinstance(other, Song):
            return NotImplemented
        return self.seconds < other.seconds

    def __add__(self, other):                 # song + song -> a Playlist
        if isinstance(other, Song):
            return Playlist([self, other])
        return NotImplemented                 # honest: "not mine, try yours"

class Playlist:
    def __init__(self, songs):
        self.songs = list(songs)

    def __repr__(self):
        return f"Playlist({self.songs!r})"

    def __len__(self):
        return len(self.songs)

    def __add__(self, other):
        return Playlist(self.songs + other.songs)

a = Song("Blinding Lights", 200)
b = Song("Titanium", 245)
c = Song("bad guy", 194)

print(a < b, b < a)
print(sorted([a, b, c]))
print(min([a, b, c]), "|", max([a, b, c]))
print(a + b, "|", len(a + b))
print(len(Playlist([a, b]) + Playlist([c])))
try:
    a + 5
except TypeError as e:
    print("TypeError:", e)

you see
True False
[Song('bad guy', 194), Song('Blinding Lights', 200), Song('Titanium', 245)]
Song('bad guy', 194) | Song('Titanium', 245)
Playlist([Song('Blinding Lights', 200), Song('Titanium', 245)]) | 2
3
TypeError: unsupported operand type(s) for +: 'Song' and 'int'

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

from functools import total_ordering

@total_ordering
class Track:
    def __init__(self, title, artist, seconds):
        self.title, self.artist, self.seconds = title, artist, seconds

    def __repr__(self):
        return f"Track({self.title!r}, {self.seconds})"

    def __eq__(self, other):
        if not isinstance(other, Track):
            return NotImplemented
        return (self.title, self.artist) == (other.title, other.artist)

    def __hash__(self):                       # __eq__ took the free one away
        return hash((self.title, self.artist))

    def __lt__(self, other):
        if not isinstance(other, Track):
            return NotImplemented
        return (self.seconds, self.title) < (other.seconds, other.title)

a = Track("Blinding Lights", "The Weeknd", 200)
b = Track("Blinding Lights", "The Weeknd", 200)
c = Track("Titanium", "David Guetta", 245)
d = Track("bad guy", "Billie Eilish", 194)

print("value equality :", a == b, "| identity:", a is b)
print("a != c         :", a != c)
print("sorted         :", sorted([a, c, d]))
print("min / max      :", min([a, c, d]), "|", max([a, c, d]))
print("total_ordering :", a < c, c >= a, d <= a)
print("set dedupes    :", len({a, b, c}))
print("foreign type   :", a == "Blinding Lights")
print("dict key       :", {a: "night drive"}[b])

# ------------- what it prints -------------
value equality : True | identity: False
a != c         : True
sorted         : [Track('bad guy', 194), Track('Blinding Lights', 200), Track('Titanium', 245)]
min / max      : Track('bad guy', 194) | Track('Titanium', 245)
total_ordering : True True True
set dedupes    : 2
foreign type   : False
dict key       : night drive

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. That's the perfect place to reject a negative running time before it can corrupt your data.

you type
class Song:
    def __init__(self, title, seconds):
        self.title = title
        self.seconds = seconds              # this goes through the setter below

    @property
    def seconds(self):                      # the getter: reads like plain data
        return self._seconds

    @seconds.setter
    def seconds(self, value):               # runs on every assignment
        if value < 0:
            raise ValueError("a song cannot run negative time")
        self._seconds = value

    @property
    def minutes(self):                      # computed on demand, never stored
        return round(self._seconds / 60, 2)

bl = Song("Blinding Lights", 200)
print(bl.seconds, bl.minutes)               # no parentheses at the call site
bl.seconds = 245
print(bl.seconds, bl.minutes)               # recomputed -- it cannot drift
print(bl.__dict__)                          # only _seconds was ever stored
try:
    bl.seconds = -1
except ValueError as e:
    print("ValueError:", e)
try:
    bl.minutes = 5
except AttributeError as e:
    print("AttributeError:", e)
print(type(Song.__dict__["minutes"]).__name__)

you see
200 3.33
245 4.08
{'title': 'Blinding Lights', '_seconds': 245}
ValueError: a song cannot run negative time
AttributeError: property 'minutes' of 'Song' object has no setter
property

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. And that sets up the single biggest misconception in the language. 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. →

# playlist.py -- the capstone. A Playlist HAS Songs, and speaks Python's own language.

class Song:
    def __init__(self, title, artist, seconds):
        self.title = title
        self.artist = artist
        self.seconds = seconds

    def __repr__(self):
        return f"Song({self.title!r}, {self.artist!r}, {self.seconds})"

    def __str__(self):
        minutes, secs = divmod(self.seconds, 60)
        return f"{self.title} - {self.artist} ({minutes}:{secs:02d})"


class Playlist:
    def __init__(self, name, songs=None):
        self.name = name
        self.songs = list(songs) if songs else []      # our own list, never the caller's

    # --- behaviour, built from chapters 6 to 10 ---
    def add(self, song):
        self.songs.append(song)                        # ch 6
        return self                                    # so calls can chain

    def remove(self, title):
        before = len(self.songs)
        self.songs = [s for s in self.songs if s.title != title]    # ch 10
        return before - len(self.songs)

    def total_seconds(self):
        return sum(s.seconds for s in self.songs)      # ch 10

    def longest(self):
        return max(self.songs, key=lambda s: s.seconds) if self.songs else None

    def by_artist(self):
        index = {}
        for s in self.songs:
            index.setdefault(s.artist, []).append(s.title)          # ch 7
        return index

    def sorted_by_length(self):
        return sorted(self.songs, key=lambda s: s.seconds)          # ch 10

    # --- the sockets, from this chapter ---
    def __len__(self):
        return len(self.songs)

    def __getitem__(self, i):
        return self.songs[i]

    def __add__(self, other):
        return Playlist(f"{self.name} + {other.name}", self.songs + other.songs)

    def __str__(self):
        minutes, secs = divmod(self.total_seconds(), 60)
        lines = [f"{self.name} - {len(self)} songs - {minutes}:{secs:02d}"]
        lines += [f"  {i}. {song}" for i, song in enumerate(self.songs, 1)]
        return "\n".join(lines)


night = Playlist("Night drive")
night.add(Song("Blinding Lights", "The Weeknd", 200))
night.add(Song("Titanium", "David Guetta", 245))
night.add(Song("Levels", "Avicii", 203))

print(night)
print()
print("len(night)         ->", len(night))
print("night[0]           ->", night[0])
print("total_seconds()    ->", night.total_seconds())
print("longest()          ->", night.longest())
print("sorted_by_length() ->", [s.title for s in night.sorted_by_length()])
print("by_artist()        ->", night.by_artist())
print("remove('Levels')   ->", night.remove("Levels"), "removed,", len(night), "left")

gym = Playlist("Gym", [Song("Uptown Funk", "Mark Ronson", 270)])
both = night + gym
print()
print(both)
print("looping the object ->", [s.title for s in both])

Night drive - 3 songs - 10:48
  1. Blinding Lights - The Weeknd (3:20)
  2. Titanium - David Guetta (4:05)
  3. Levels - Avicii (3:23)

len(night)         -> 3
night[0]           -> Blinding Lights - The Weeknd (3:20)
total_seconds()    -> 648
longest()          -> Titanium - David Guetta (4:05)
sorted_by_length() -> ['Blinding Lights', 'Levels', 'Titanium']
by_artist()        -> {'The Weeknd': ['Blinding Lights'], 'David Guetta': ['Titanium'], 'Avicii': ['Levels']}
remove('Levels')   -> 1 removed, 2 left

Night drive + Gym - 3 songs - 11:55
  1. Blinding Lights - The Weeknd (3:20)
  2. Titanium - David Guetta (4:05)
  3. Uptown Funk - Mark Ronson (4:30)
looping the object -> ['Blinding Lights', 'Titanium', 'Uptown Funk']