Polymorphism Basics

By the end of this lesson you can:

• Define polymorphism: same interface, different implementations.
• Write a loop that works on any object with the right method name.
• Explain "duck typing" — if it walks and talks like a duck, treat it as a duck.
• Use a common parent class to make polymorphism explicit.

Every for x in something: loop is polymorphic. The same loop works for a list, a string, a dict, a set, a file — because they all support iteration.

for ch in "hello":        print(ch)
for n in [1, 2, 3]:        print(n)
for line in open("x.txt"): print(line)

Three completely different types. Same syntax. That's polymorphism — and Python relies on it everywhere.

1 · Inheritance polymorphism

The classic shape. All children share a parent; each overrides a method.

class Animal:
    def speak(self):
        raise NotImplementedError("Subclasses must override speak()")

class Dog(Animal):
    def speak(self): print("Woof!")

class Cat(Animal):
    def speak(self): print("Meow.")

class Cow(Animal):
    def speak(self): print("Moo.")

zoo = [Dog(), Cat(), Cow()]
for a in zoo:
    a.speak()        # Python picks the right speak() automatically

The loop says a.speak(). Python looks at a's class, finds the right method. Three different printouts from the same line of code.

The parent's raise NotImplementedError trick is a way to say "every child must override this" — if someone forgets, they get a clear error instead of mysterious behaviour.

2 · Duck typing — no parent needed

Python doesn't even require a common parent. Anything with the right method works.

class Duck:
    def speak(self): print("Quack!")

class Person:
    def speak(self): print("Hello!")

class Doorbell:
    def speak(self): print("Ding-dong.")

# No inheritance at all — but they all have .speak()
things = [Duck(), Person(), Doorbell()]
for t in things:
    t.speak()

This is "duck typing" — the famous Python proverb: If it walks like a duck and quacks like a duck, treat it as a duck. The loop only cares that t.speak() works.

For small programs, this is wonderfully flexible. For big ones, sharing a parent class makes the contract explicit — "everything in this list is an Animal".

3 · Polymorphism with built-ins

Many builtins use polymorphism. len(x) works for any x with a __len__ method:

len("hi")           # → 2     (str.__len__)
len([1, 2, 3])      # → 3     (list.__len__)
len({1: "a"})       # → 1     (dict.__len__)

class Box:
    def __init__(self, items):
        self.items = items
    def __len__(self):
        return len(self.items)

len(Box([1, 2, 3, 4]))   # → 4   — works on your class too!

Same len() function. Different __len__ implementations. You can make your own class "len-able" just by defining __len__ — Python doesn't care about ancestry. We'll meet this trick properly in PY-L3-16.

The benefit · loop once, scale forever

Add a new Animal? The zoo loop doesn't change.

class Sheep(Animal):
    def speak(self): print("Baa.")

zoo.append(Sheep())
for a in zoo:
    a.speak()              # same loop — handles Sheep now too

This is how big software grows — add new types without touching old code. The opposite is the "giant if-elif chain":

# ❌ Not polymorphism — fragile
for a in zoo:
    if isinstance(a, Dog):       print("Woof!")
    elif isinstance(a, Cat):     print("Meow.")
    elif isinstance(a, Cow):     print("Moo.")
    elif isinstance(a, Sheep):   print("Baa.")
    # ... and on, and on, every new animal needs a new branch

If you ever catch yourself writing a chain of isinstance checks, polymorphism is usually the fix.

A realistic example. Save as notify.py:

# notify.py — different notification channels, same interface

class Channel:
    """A channel that can send a notification. Children override .send()."""
    def send(self, message):
        raise NotImplementedError


class EmailChannel(Channel):
    def __init__(self, address):
        self.address = address

    def send(self, message):
        print(f"  📧 Email to {self.address}: {message}")


class SMSChannel(Channel):
    def __init__(self, phone):
        self.phone = phone

    def send(self, message):
        print(f"  📱 SMS to {self.phone}: {message[:160]}")


class PushChannel(Channel):
    def __init__(self, device_id):
        self.device_id = device_id

    def send(self, message):
        print(f"  🔔 Push to device {self.device_id}: {message}")


class LoggingChannel(Channel):
    def send(self, message):
        from datetime import datetime
        ts = datetime.now().isoformat(timespec="seconds")
        print(f"  📝 [{ts}] LOG: {message}")


def notify_all(channels, message):
    """Send the same message to every channel. Polymorphic by design."""
    for ch in channels:
        ch.send(message)


# The user's preferred channels — could be any mix of types
my_channels = [
    EmailChannel("aisyah@example.com"),
    SMSChannel("012-3456789"),
    PushChannel("device-42"),
    LoggingChannel(),
]

notify_all(my_channels, "Your order has shipped!")

Output

  📧 Email to aisyah@example.com: Your order has shipped!
  📱 SMS to 012-3456789: Your order has shipped!
  🔔 Push to device device-42: Your order has shipped!
  📝 [22:31:04] LOG: Your order has shipped!

Read the diff

notify_all is six lines and knows nothing about email, SMS, push or logs. It only knows that every channel has a send method. Tomorrow you can add Slack, WhatsApp, or a Discord webhook — define the class, override send, and the same notify_all handles it. That's the design power. Every big system uses this shape.

Polymorphism is "same method name, different classes". Code that calls x.method() works for any x that has the method — regardless of class. Two flavours: inheritance polymorphism uses a shared parent (explicit contract); duck typing doesn't need a parent (flexible, Pythonic). Both let you write code that scales: add a new class, no caller changes. If you ever find yourself writing a chain of isinstance checks, replace it with a method on each class.