Polymorphism — duck typing, same interface different behavior: Exercises

Figure — Polymorphism — duck typing, same interface different behavior

The figure above is our compass: one call site (the amber button) fans out to many objects, and each object supplies its own method body. Keep this picture in mind — every exercise is a variation on it.

Level 1 — Recognition

Goal: spot polymorphism, and spot when it is NOT happening.

Worked example L1.1 — Is this polymorphism?

For each snippet, answer YES (polymorphism) or NO, and say which flavor (duck typing / subtype override / operator) when YES.

(a)

"ab" + "cd"
[1] + [2]

(b)

def greet(x):
    return x.speak()
greet(Dog()); greet(Robot())   # Dog, Robot unrelated classes

(c)

def f(n):
    return n * 2
f(3); f("hi")

Recall Solution L1.1

(a) YES — operator polymorphism. The same name + dispatches to str.__add__ (concatenate) and list.__add__ (concatenate lists). One symbol, two method bodies chosen by type(left).

(b) YES — duck typing. greet never names a class. It only needs x to have .speak(). Dog and Robot share no base class, yet both fit the implicit interface.

(c) YES — operator polymorphism (subtle!). * calls int.__mul__ on 3*2 → 6 and str.__mul__ on "hi"*2 → "hihi". Same operator, different behavior per type. Many students say "NO, it's just one function f" — but the polymorphism lives inside *, not in f.

Worked example L1.2 — Which line breaks?

class Duck:
    def quack(self): return "Quack"
class Dog:
    def bark(self): return "Woof"
 
def noise(a): return a.quack()
 
noise(Duck())   # line A
noise(Dog())    # line B

Which call raises, what error, and why — precisely in terms of method lookup?

Recall Solution L1.2

Line A works → "Quack". Line B raises AttributeError.

Why: at runtime noise executes a.quack(). Python searches quack along type(a).__mro__. For Dog, the MRO is [Dog, object] — no quack anywhere → AttributeError: 'Dog' object has no attribute 'quack'. Dog does have bark, but we never call bark, so it doesn't save us. The interface required is quack, and Dog doesn't satisfy it.

Level 2 — Application

Goal: write small polymorphic code and predict its output.

Worked example L2.1 — Predict the output

import math
class Circle:
    def __init__(self, r): self.r = r
    def area(self): return math.pi * self.r**2
class Square:
    def __init__(self, s): self.s = s
    def area(self): return self.s**2
class Rectangle:
    def __init__(self, w, h): self.w, self.h = w, h
    def area(self): return self.w * self.h
 
def total_area(shapes):
    return sum(s.area() for s in shapes)
 
print(round(total_area([Circle(2), Square(3), Rectangle(2, 5)]), 4))

Compute the printed number by hand. (Reminder: $π$ in the maths below is the same number as math.pi in the code.)

Recall Solution L2.1

Each shape answers area() in its own way — same call, different body:

Circle(2) → $π r^{2} = π \cdot 2^{2} = 4 π \approx 12.566370614$ (here $π =$ math.pi $\approx 3.14159$ )
Square(3) → $s^{2} = 3^{2} = 9$
Rectangle(2,5) → $w \cdot h = 2 \cdot 5 = 10$

Sum $= 4 π + 9 + 10 = 4 π + 19 \approx 31.566370614$ . Rounded to 4 places: $31.5664$ .

$total = π \cdot 2^{2} + 3^{2} + (2 \cdot 5) = 4 π + 19$

Recall Solution L2.2

class Triangle:
    def __init__(self, b, h): self.b, self.h = b, h
    def area(self): return 0.5 * self.b * self.h

Triangle needs no inheritance — it only satisfies the implicit interface "has area()". That is exactly why total_area never changes.

Triangle(6,4) → $\frac{1}{2} \cdot 6 \cdot 4 = 12$ . So total_area([Triangle(6,4)]) = 12.0.
total_area([Circle(1), Triangle(6,4)]) $= π \cdot 1^{2} + 12 = π + 12 \approx 15.1416$ (again $π =$ math.pi).

The figure above shows why total_area never changes: each shape holds its own area() body (cyan boxes), yet the loop calls them through the one shared interface. The amber labels are the different formulas — different maths, identical call s.area().

Worked example L2.3 — Duck-typed total cost

class Book:
    def __init__(self, price): self.price = price
class Coffee:
    def __init__(self, price): self.price = price
 
def total(items):
    return sum(i.price for i in items)
 
print(total([Book(299), Coffee(120), Book(450)]))

Predict the printed value. Then: if we append an object object() (a bare object) to the list, exactly what happens?

Recall Solution L2.3

Sum of .price attributes: $299 + 120 + 450 = 869$ . Prints 869.

total codes an interface (has .price), not a type — Book and Coffee are unrelated yet both fit. Add object() and the generator hits i.price on a plain object → AttributeError: 'object' object has no attribute 'price', raised the moment that item is reached. The lookup failed along type(i).__mro__ = [object].

Level 3 — Analysis

Goal: reason about method lookup, MRO, and where things go wrong.

Worked example L3.1 — Override vs untouched siblings

class Animal:
    def speak(self): return "..."
class Dog(Animal):
    def speak(self): return "Woof"
class Cat(Animal):
    pass                       # no override
 
print(Dog().speak())
print(Cat().speak())
print(Animal().speak())

Give all three outputs and explain each via the MRO.

Recall Solution L3.1

Dog().speak() → "Woof". MRO [Dog, Animal, object]; speak found on Dog first → its override runs.
Cat().speak() → "...". MRO [Cat, Animal, object]; Cat has no speak, so lookup walks to Animal and finds the base version.
Animal().speak() → "...". Animal itself defines speak.

Key insight: overriding in Dog changes only Dog's lookup. Cat and Animal are untouched. Each object resolves speak along its own Method Resolution Order (MRO).

Worked example L3.2 — LBYL breaks polymorphism

Two implementations of "make everything speak" (LBYL = "Look Before You Leap"; EAFP = "Easier to Ask Forgiveness than Permission"):

# Version A (LBYL — check type before calling)
def speak_all_A(things):
    out = []
    for t in things:
        if isinstance(t, (Dog, Cat)):
            out.append(t.speak())
    return out
 
# Version B (EAFP — just call, catch failure)
def speak_all_B(things):
    out = []
    for t in things:
        try:
            out.append(t.speak())
        except AttributeError:
            pass
    return out

A new class Robot (with speak, no relation to Dog/Cat) is added. For input [Dog(), Cat(), Robot()], how many strings does each version return, and why does the difference matter?

Recall Solution L3.2

Assume Dog, Cat, Robot each define speak.

Version A (LBYL) returns 2 items (Dog, Cat). Robot fails the isinstance check and is silently dropped — even though it can speak! The type-check rejected a perfectly valid duck.
Version B (EAFP) returns 3 items (Dog, Cat, Robot). It just asks each object to speak; every object that has speak succeeds.

Why it matters: Version A must be edited every time a new speaker appears. Version B needs zero edits — this is EAFP preserving extensibility, the whole payoff of polymorphism.

Recall Solution L3.3

Dog() → has speak → appended. ✅
Cat() → has speak → appended. ✅
Robot() → has speak → appended. ✅
object() → no speak → AttributeError caught → skipped. ❌
42 (int) → no speak → AttributeError caught → skipped. ❌

Total appended = 3. EAFP lets the good ducks through and quietly declines the rest.

Level 4 — Synthesis

Goal: design polymorphic systems, including operator/dunder polymorphism.

Worked example L4.1 — A polymorphic

Money with __add__ Build a class so that money adds like a number but keeps cents correct:

class Money:
    def __init__(self, cents): self.cents = cents
    def __add__(self, other):
        return Money(self.cents + other.cents)
    def __str__(self):
        return f"${self.cents/100:.2f}"

What does str(Money(150) + Money(275)) produce? Explain which dunder runs at each step.

Recall Solution L4.1

Step by step:

Money(150) + Money(275) → Python sees +, calls Money.__add__(left, right). This returns Money(150 + 275) = Money(425).
str(...) → Python calls Money.__str__, giving f"${425/100:.2f}" = "$4.25".

Output: "$4.25". This is operator polymorphism you authored: the same + symbol now has meaning for Money because you supplied its __add__ body. See Dunder methods — __add__, __len__, __str__.

Worked example L4.2 — Polymorphic

len via __len__

class Playlist:
    def __init__(self, songs): self.songs = songs
    def __len__(self): return len(self.songs)
 
class Team:
    def __init__(self, members): self.members = members
    def __len__(self): return len(self.members)
 
print(len(Playlist(["a","b","c"])) + len(Team(["x","y"])))

Predict the printed integer, and state the general rule len(obj) obeys.

Recall Solution L4.2

len(obj) is polymorphic: it simply calls type(obj).__len__(obj). So:

len(Playlist([...3...])) → 3
len(Team([...2...])) → 2
Sum → 5.

Rule: len(x) ⟶ type(x).__len__(x); any object supplying __len__ becomes "measurable", no inheritance needed.

Worked example L4.3 — Design a plugin

render pipeline You want a function render_all(nodes) that returns the total character length of everything rendered, where each node renders differently:

class Text:
    def __init__(self, s): self.s = s
    def render(self): return self.s
class Bold:
    def __init__(self, s): self.s = s
    def render(self): return f"**{self.s}**"
class Link:
    def __init__(self, label, url): self.label, self.url = label, url
    def render(self): return f"[{self.label}]({self.url})"

Write render_all in one line using the shared render() interface, then compute render_all([Text("hi"), Bold("go"), Link("A", "u")]) as a character count.

Recall Solution L4.3

def render_all(nodes):
    return sum(len(n.render()) for n in nodes)

It relies only on the render() interface — pure duck typing. Now the pieces:

Text("hi").render() → "hi" → length 2
Bold("go").render() → "**go**" → length 6 (2 stars + go + 2 stars = 6)
Link("A","u").render() → "[A](u)" → length 6 ([ A ] ( u ))

Total = $2 + 6 + 6 =$ 14. Add a Heading class tomorrow with its own render() → render_all never changes.

Level 5 — Mastery

Goal: combine inheritance, override, super(), and duck typing under one roof.

Worked example L5.1 — Override chain with

super()

class Shape:
    def describe(self): return "shape"
class Polygon(Shape):
    def describe(self): return "polygon: " + super().describe()
class Square(Polygon):
    def describe(self): return "square: " + super().describe()
 
print(Square().describe())

Give the exact printed string and trace the MRO calls.

Recall Solution L5.1

MRO of Square = [Square, Polygon, Shape, object].

Square.describe runs → "square: " + super().describe(). super() in Square means "next after Square in the MRO" = Polygon.
Polygon.describe runs → "polygon: " + super().describe(). super() here = Shape.
Shape.describe runs → "shape".

Unwinding: "polygon: " + "shape" = "polygon: shape", then "square: " + "polygon: shape". Final: "square: polygon: shape". This is override + super() cooperating along the MRO.

Worked example L5.2 — Mixed pipeline: inheritance AND duck typing together

class Animal:
    def speak(self): raise NotImplementedError
class Dog(Animal):
    def speak(self): return "Woof"
class Cat(Animal):
    def speak(self): return "Meow"
class Horn:                       # not an Animal at all
    def speak(self): return "Beep"
 
def chorus(things):
    return " ".join(t.speak() for t in things)
 
print(chorus([Dog(), Cat(), Horn()]))

What is printed? Then: what happens if a plain Animal() is included, and how would you prevent that class of bug at design time?

Recall Solution L5.2

chorus uses only the speak() interface, so Horn (no inheritance) joins the Animal subclasses seamlessly: "Woof Meow Beep".

If Animal() itself is included, Animal.speak runs raise NotImplementedError → the whole chorus blows up with NotImplementedError. To prevent this at design time, make Animal a true abstract base class so it cannot be instantiated:

from abc import ABC, abstractmethod
class Animal(ABC):
    @abstractmethod
    def speak(self): ...

Now Animal() raises TypeError immediately — you catch the mistake at construction, not deep in the pipeline. See Abstraction — interfaces and abstract base classes (ABC).

Worked example L5.3 — Full synthesis with a number

Combine everything. Given:

class Node:
    def cost(self): return 0
class Item(Node):
    def __init__(self, c): self.c = c
    def cost(self): return self.c
class Bundle(Node):
    def __init__(self, parts): self.parts = parts
    def cost(self): return sum(p.cost() for p in self.parts)   # recursive, polymorphic
 
tree = Bundle([Item(100), Bundle([Item(30), Item(20)]), Item(5)])
print(tree.cost())

Compute the total cost, explaining why Bundle.cost works without knowing whether each part is an Item or another Bundle.

Recall Solution L5.3

Bundle.cost calls p.cost() on each part. Thanks to polymorphism it doesn't care if p is an Item (returns its price) or a Bundle (recurses). Same call cost(), different body — a recursive composite tree.

Evaluate inside out:

Inner Bundle([Item(30), Item(20)]) → $30 + 20 = 50$
Outer Bundle([Item(100), 50, Item(5)]) → $100 + 50 + 5 = 155$

Printed: 155. This composite pattern is polymorphism's endgame: uniform interface across a whole tree of different node types.

Recall One-line summary of the whole page

Every exercise reduces to one truth ::: x.method() resolves method along type(x).__mro__ at runtime — same call site, object-chosen body — so any object honoring the interface plugs in with zero caller changes.

Connections

Parent topic (Hinglish)
Inheritance — overriding and super()
Abstraction — interfaces and abstract base classes (ABC)
Dunder methods — __add__, __len__, __str__
Method Resolution Order (MRO)
EAFP vs LBYL — Pythonic error handling
Liskov Substitution Principle (SOLID)