Solved exercise: shopping receipt with classes and dunders in Python

The solution rests on three ideas. First, an abstract base class gathers all the shared behaviour. Second, two minimal subclasses contribute only the amount calculation and the detail text. Third, a container, Receipt, behaves like a Python collection thanks to __len__ and __iter__. Money stays in integer cents throughout and is turned into text only at the last moment, in the function money.

If you want to revisit classes, constructors and inheritance first, the blog covers the same ground in Java in Solved exercise: inheritance, constructors and super in Java. The ideas carry over to Python almost unchanged. The differences are super() and the special methods.

import sys
from abc import ABC, abstractmethod


def money(cents):
    """Format non-negative integer cents as 20.48."""
    return f"{cents // 100}.{cents % 100:02d}"


class Line(ABC):
    RANK = 9  # tie-break position by type; subclasses override it

    def __init__(self, name, price, quantity):
        if price <= 0 or quantity <= 0:
            raise ValueError("price and quantity must be positive")
        self.name = name
        self.price = price
        self.quantity = quantity

    @abstractmethod
    def amount(self):
        """Amount of the line in cents."""

    @abstractmethod
    def detail(self):
        """Text between the name and the equals sign."""

    def __eq__(self, other):
        if not isinstance(other, Line):
            return NotImplemented
        return (type(self) is type(other)
                and self.name == other.name
                and self.price == other.price)

    def __hash__(self):
        return hash((type(self), self.name, self.price))

    def __add__(self, other):
        if not isinstance(other, Line):
            return NotImplemented
        if self != other:
            raise ValueError("cannot add different products")
        return type(self)(self.name, self.price,
                          self.quantity + other.quantity)

    def sort_key(self):
        return (-self.amount(), self.name, self.RANK, self.price)

    def __str__(self):
        return f"{self.name} {self.detail()} = {money(self.amount())}"


class UnitLine(Line):
    RANK = 1

    def amount(self):
        return self.price * self.quantity

    def detail(self):
        return f"{self.quantity} x {money(self.price)}"


class WeightLine(Line):
    RANK = 0

    def amount(self):
        # price in cents per kg, quantity in grams; halves round up
        return (self.price * self.quantity + 500) // 1000

    def detail(self):
        return f"{self.quantity} g at {money(self.price)}/kg"


class Receipt:
    def __init__(self):
        self._lines = []

    def add(self, line):
        for i, existing in enumerate(self._lines):
            if existing == line:
                self._lines[i] = existing + line
                return
        self._lines.append(line)

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

    def __iter__(self):
        return iter(sorted(self._lines, key=Line.sort_key))

    def total(self):
        return sum(line.amount() for line in self._lines)

    def __str__(self):
        rows = [str(line) for line in self]
        rows.append(f"Lines: {len(self)}")
        rows.append(f"TOTAL: {money(self.total())}")
        return "\n".join(rows)


KINDS = {"U": UnitLine, "W": WeightLine}


def main():
    receipt = Receipt()
    for text in sys.stdin:
        parts = text.split()
        if not parts:
            continue
        cls = KINDS[parts[0]]
        receipt.add(cls(parts[1], int(parts[2]), int(parts[3])))
    print(receipt)


main()

The base class. Line inherits from ABC and declares amount and detail as abstract methods. As a result, Line("x", 1, 1) raises TypeError, and so does any subclass that forgets one of the two methods. The constructor checks that price and quantity are positive. The statement guarantees valid input, but an object should never be born in an impossible state. The class attribute RANK drives the tie-break by type. WeightLine sets it to 0 and UnitLine to 1, so weight lines sort first.

Equality and hashing. __eq__ returns NotImplemented when the other operand is not a line. Python then tries the reflected comparison, and if that also fails the result is False. The comparison uses type(self) is type(other) rather than isinstance, because a weight line and a unit line with the same name and price are not the same product. Overriding __eq__ makes Python set __hash__ to None, so we redefine it from the same tuple of fields. Equal objects then share a hash, as set and dict require.

Merging with +. __add__ reuses equality (self != other) to reject different products. It builds the result with type(self)(...), which lets the merge be written once in the base class. If self is a WeightLine, the result is a WeightLine. Neither operand is modified; a new object is returned, as + does for numbers and strings. Nobody holding a reference to the original line gets a surprise.

The subclasses. UnitLine.amount just multiplies. WeightLine.amount computes (self.price * self.quantity + 500) // 1000, which rounds halves up in pure integer arithmetic. The test "rounding and merging loose items" checks exactly this. One gram of walnuts at 15.00/kg is worth 1.5 cents and is printed as 0.02. The two 2 g lines of grapes merge into 4 g worth 1 cent, not 2. The base __str__ builds the line by calling detail() and amount(), which dynamic dispatch resolves in the subclass.

The container. Receipt.add scans the list. If it finds an equal line (existing == line), it replaces it with existing + line; otherwise it appends the new line. __len__ makes len(receipt) work. __iter__ returns an iterator over the list sorted with key=Line.sort_key. That key is the tuple (-amount, name, RANK, price), which encodes the required order. The amount is negated so that larger amounts come first. Finally, __str__ loops over self, which calls __iter__, and appends the count and the total.

Checking against the tests. In the example, cheese appears twice, at 250 g and at 130 g. The two records merge into one 380 g line worth 7.18, and the coffees merge into 3 units. The test "same name, different products, ties" has three bread lines that never merge with each other: two unit lines with different prices and one weight line. It also has a tie at 3.00 between loose bread and juice, settled by name. Empty input prints Lines: 0 and TOTAL: 0.00, because sum of an empty sequence is 0. The large-amounts test shows that money needs no thousands separator.