Classes in depth

Abstract base classes: a contract

Sometimes a base class exists only to say "every subclass must have these methods". An abstract base class (ABC) makes that a rule Python enforces:

from abc import ABC, abstractmethod

class Shipping(ABC):
    @abstractmethod
    def cost(self, weight_kg):
        """What this method charges, in dollars."""

    def quote(self, weight_kg):
        return f"{type(self).__name__}: ${self.cost(weight_kg):.2f}"

class Standard(Shipping):
    def cost(self, weight_kg):
        return 6.0 if weight_kg < 5 else 6.0 + 1.5 * (weight_kg - 5)

class Express(Shipping):
    def cost(self, weight_kg):
        return 15.0 + 2.0 * weight_kg

for method in [Standard(), Express()]:
    print(method.quote(8))

class Pigeon(Shipping):
    pass

try:
    Pigeon()
except TypeError as e:
    print("refused:", e)

Shipping can't be created itself, and neither can a subclass that forgets cost: the error comes when you create the object, not later in front of a customer. Shared behavior like quote still lives in the base class and calls the subclass's cost. Code that receives "some kind of shipping" can rely on both methods being there.

Dataclasses, tuned

The types lesson introduced @dataclass. A few options make dataclasses safer and faster:

from dataclasses import dataclass, field

@dataclass(frozen=True, slots=True)
class Sku:
    code: str

    def __post_init__(self):
        if len(self.code) != 6 or self.code[2] != "-":
            raise ValueError(f"not a SKU: {self.code!r}")

@dataclass
class Cart:
    owner: str
    items: dict = field(default_factory=dict)
    tags: list = field(default_factory=list)

    def add(self, sku, qty=1):
        self.items[sku] = self.items.get(sku, 0) + qty

a, b = Cart("ada"), Cart("ben")
a.add(Sku("TE-101"))
print(a.items, b.items)
print(Sku("TE-101") == Sku("TE-101"), hash(Sku("TE-101")) == hash(Sku("TE-101")))
try:
    Sku("tent")
except ValueError as e:
    print("refused:", e)

• field(default_factory=dict) gives each cart its own dictionary. Writing items: dict = {} is refused, because every cart would share one dictionary: the shared-list bug from the inheritance lesson.
• __post_init__ runs right after the generated __init__: the place for validation.
• frozen=True makes objects read-only after creation, so they can be dictionary keys and set members. Assigning sku.code = "x" raises an error.
• slots=True stores fields in fixed slots instead of a per-object dictionary: less memory per object, and a typo like cart.ownr = ... fails instead of silently adding an attribute.

class Thermostat:
    def __init__(self, target):
        self.target = target


t = Thermostat(21)
print(t.target, t.fahrenheit)

Which method runs? Method resolution order

With several layers of inheritance, Python needs a rule for where to look first. It builds the class's method resolution order (MRO): the class itself, then its parents left to right, each before its own parents. super() means "the next class in that order", not simply "my parent":

class Base:
    def describe(self):
        return ["base"]

class Waterproof(Base):
    def describe(self):
        return ["waterproof"] + super().describe()

class Insulated(Base):
    def describe(self):
        return ["insulated"] + super().describe()

class WinterBoot(Waterproof, Insulated):
    def describe(self):
        return ["winter boot"] + super().describe()

print(WinterBoot().describe())
print([c.__name__ for c in WinterBoot.__mro__])

Each super().describe() passes the call along the MRO, so Base runs exactly once, at the end. Small, focused classes combined like this are called mixins. Use them sparingly. When a hierarchy needs a diagram to explain, giving an object another object to use (composition) is usually clearer than inheriting from both.

Where you'll meet these

These tools aren't academic. They're how the libraries you'll use every day are built:

• Properties are everywhere in data libraries. A pandas DataFrame's shape, columns and T (its transpose) are properties: they look like stored values but are worked out when you ask. Django and SQLAlchemy models use them for computed fields like a full name built from two columns.
• Class methods as constructors are the standard way to offer several ways in: datetime.fromisoformat, pd.DataFrame.from_records, dict.fromkeys. Whenever data can arrive in more than one shape, give each shape its own from_... method rather than one __init__ full of if statements.
• Abstract base classes define plug-in points. The standard library's collections.abc has ABCs like Mapping and Iterable, and frameworks use them for "write a subclass that fills in these methods": a storage backend, a payment provider, a model in a training framework.
• Frozen dataclasses suit values that shouldn't change once made: a product code, a money amount, a configuration. Immutable objects are easier to reason about, safe to share, and can be dictionary keys.

The common thread is putting rules in one place. A rule in a property or __post_init__ holds for every object, however it was created. A rule repeated at every call site is one that someone will eventually forget.

from abc import ABC, abstractmethod

class Account(ABC):
    def __init__(self, owner, balance=0.0):
        self.owner = owner
        self.balance = balance

    @property
    def balance(self):
        return self._balance

    @balance.setter
    def balance(self, value):
        if value < 0:
            raise ValueError("balance can't go below zero")
        self._balance = round(value, 2)

    @abstractmethod
    def monthly_fee(self):
        ...

    def charge_fee(self):
        self.balance -= min(self.monthly_fee(), self.balance)

    @classmethod
    def from_dict(cls, data):
        return cls(data["owner"], data["balance"])

class Basic(Account):
    def monthly_fee(self):
        return 2.0

class Club(Account):
    def monthly_fee(self):
        return 0.0 if self.balance >= 100 else 1.0

accounts = [Basic.from_dict({"owner": "Ada", "balance": 50}), Club.from_dict({"owner": "Ben", "balance": 120}),
            Club.from_dict({"owner": "Cy", "balance": 0.5})]
for acct in accounts:
    acct.charge_fee()
    print(type(acct).__name__, acct.owner, acct.balance)