Encapsulation and Magic/Dunder Methods

class Account:
    def __init__(self, balance):
        self.balance = balance        # public — freely accessed from outside
        self._pin = "1234"            # "protected" — a hint: internal use, please don't touch
        self.__secret_key = "xyz789"  # "private" — name-mangled, harder to access accidentally

acc = Account(500)
print(acc.balance)     # 500 — totally fine, it's public
print(acc._pin)        # "1234" — WORKS. Python does not stop you. It's a convention, not a lock.
print(acc.__secret_key)  # AttributeError! (see Part 02 — this one actually does something)

class Account:
    def __init__(self):
        self.__secret_key = "xyz789"

acc = Account()
print(acc.__dict__)
# {'_Account__secret_key': 'xyz789'}  <- the REAL attribute name, mangled

print(acc.__secret_key)          # AttributeError — this name doesn't exist
print(acc._Account__secret_key)  # "xyz789" — still fully accessible if you know the mangled name

class Product:
    def __init__(self, name, price):
        self.name = name
        self.price = price

p = Product("Keyboard", 79.99)
print(p)     # <__main__.Product object at 0x7f8a1c0a5d90>

class Product:
    def __init__(self, name, price):
        self.name = name
        self.price = price

    def __str__(self):
        return f"{self.name} (${self.price:.2f})"

p = Product("Keyboard", 79.99)
print(p)          # Keyboard ($79.99)  <- calls __str__
print(f"{p}")     # Keyboard ($79.99)  <- f-strings also call __str__

class Product:
    def __init__(self, name, price):
        self.name = name
        self.price = price

    def __repr__(self):
        return f"Product(name={self.name!r}, price={self.price!r})"

p = Product("Keyboard", 79.99)
p                 # Product(name='Keyboard', price=79.99)   <- shown at the REPL / in a debugger
repr(p)           # "Product(name='Keyboard', price=79.99)"  <- Python switches to double quotes here, since the string itself contains a single quote
print([p])        # [Product(name='Keyboard', price=79.99)] <- lists print elements' repr, not str!

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

p1 = Point(1, 2)
p2 = Point(1, 2)
print(p1 == p2)     # False! Different objects in memory, even though the data is identical

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __eq__(self, other):
        if not isinstance(other, Point):
            return NotImplemented
        return self.x == other.x and self.y == other.y

p1 = Point(1, 2)
p2 = Point(1, 2)
print(p1 == p2)     # True — now comparing by value

class Point:
    def __init__(self, x, y):
        self.x, self.y = x, y

    def __eq__(self, other):
        if not isinstance(other, Point):
            return NotImplemented
        return self.x == other.x and self.y == other.y

    def __hash__(self):
        return hash((self.x, self.y))   # same inputs -> same hash, matching __eq__'s logic

points = {Point(1, 2), Point(1, 2)}
print(len(points))     # 1 — correctly recognised as the same logical value

class Employee:
    def __init__(self, name, salary):
        self.name, self.salary = name, salary

    def __lt__(self, other):
        return self.salary < other.salary

    def __repr__(self):
        return f"Employee({self.name!r}, {self.salary})"

team = [Employee("Cara", 95000), Employee("Ben", 82000)]
print(sorted(team))
# [Employee('Ben', 82000), Employee('Cara', 95000)]  -- sorted() uses __lt__ automatically

from functools import total_ordering

@total_ordering
class Employee:
    def __init__(self, name, salary):
        self.name, self.salary = name, salary

    def __eq__(self, other):
        return self.salary == other.salary

    def __lt__(self, other):
        return self.salary < other.salary

# total_ordering fills in __le__, __gt__, __ge__ automatically from just these two

class Money:
    def __init__(self, cents):
        self.cents = cents

    def __add__(self, other):
        return Money(self.cents + other.cents)

    def __repr__(self):
        return f"${self.cents / 100:.2f}"

total = Money(500) + Money(250)
print(total)     # $7.50 — the + operator now works on Money objects directly

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

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

    def __getitem__(self, index):
        return self._songs[index]

pl = Playlist(["Intro", "Solo", "Outro"])
print(len(pl))       # 3           -- len() calls __len__
print(pl[1])         # "Solo"      -- indexing calls __getitem__
for song in pl:      # __getitem__ alone is even enough to make an object iterable!
    print(song)

A team defines a Shipment class with a hand-written __eq__ (comparing by tracking number) but never gets around to adding __hash__. Their code works fine for months — until someone starts collecting shipments into a set() to de-duplicate a batch import, and duplicate shipments start silently slipping through instead of being removed.

class Shipment:
    def __init__(self, tracking_number):
        self.tracking_number = tracking_number

    def __eq__(self, other):
        return self.tracking_number == other.tracking_number

    # No __hash__ defined!

s1 = Shipment("TRK001")
s2 = Shipment("TRK001")
print(s1 == s2)           # True — looks correct

unique = {s1, s2}
print(len(unique))        # 2, NOT 1! Duplicates were not removed.

Why this happens

Defining __eq__ without __hash__ does not raise an error — it silently falls back to identity-based hashing (the default from object), which is completely inconsistent with the value-based __eq__ just written. The set uses the (identity) hash to decide which bucket to check first, finds no collision because s1 and s2 hash differently, and never even calls __eq__ to compare them.

class Shipment:
    def __init__(self, tracking_number):
        self.tracking_number = tracking_number

    def __eq__(self, other):
        return self.tracking_number == other.tracking_number

    def __hash__(self):
        return hash(self.tracking_number)   # consistent with __eq__

unique = {Shipment("TRK001"), Shipment("TRK001")}
print(len(unique))        # 1 — correct now

The lesson the team took away: __eq__ and __hash__ are a matched pair — if you override one for value comparison, you almost always need to override the other, and the bug they produce when mismatched is exactly this kind of silent, hard-to-notice data corruption rather than a loud crash.