Python Polymorphism and Duck Typing

3Python Polymorphism: explained step by step

Polymorphism (Greek for "many forms") means one name, many behaviours. You call thing.send(message) or len(thing) without knowing exactly what thing is, and each kind of object does the right thing in its own way. The code that makes the call stays short and never has to ask "what are you?".

You met a first taste of this in the inheritance lesson. Here you will see the three places where polymorphism shows up in Python: overridden methods in a class family, duck typing with unrelated classes, and the built-in functions and operators themselves.

One call, many behaviours: overriding

When a parent class and its children all define a method with the same name, a call runs the version that belongs to the object it was made on. A child can replace the parent's version completely, or build on it with super():

class Sender:
    def __init__(self, recipient):
        self.recipient = recipient

    def send(self, message):
        return f"To {self.recipient}: {message}"

class EmailSender(Sender):
    def send(self, message):
        return "Email " + super().send(message)

class SmsSender(Sender):
    def send(self, message):
        return "SMS " + super().send(message[:19] + "...")    # texts must be short

class PushSender(Sender):
    def send(self, message):
        return f"Push banner for {self.recipient}: {message.upper()}"

channels = [EmailSender("asha@example.com"), SmsSender("+1-555-0100"), PushSender("Asha's phone")]
for channel in channels:
    print(channel.send("Your parcel arrives tomorrow"))

The list holds three different kinds of sender, yet the line channel.send(...) is identical for all of them. Python looks in each object's own class first, so each object gets its own behaviour. Add a fourth channel next month and the loop does not change at all.

Duck typing: "if it quacks like a duck..."

Python never checks an object's class before calling a method. At the moment of the call it only asks whether the object has that method. The saying goes: if it walks like a duck and quacks like a duck, it is a duck. So classes do not need a shared parent to be interchangeable. They just need the same method name and compatible arguments.

import json

class CsvExporter:
    def export(self, rows):
        return "\n".join(",".join(str(cell) for cell in row) for row in rows)

class JsonExporter:
    def export(self, rows):
        return json.dumps(rows)

class HtmlExporter:
    def export(self, rows):
        lines = []
        for row in rows:
            cells = "".join(f"<td>{cell}</td>" for cell in row)
            lines.append(f"<tr>{cells}</tr>")
        return "\n".join(lines)

def save_report(exporter, rows):
    print(exporter.export(rows))

rows = [("Asha", 91), ("Ben", 78)]
for exporter in [CsvExporter(), JsonExporter(), HtmlExporter()]:
    save_report(exporter, rows)

None of the three exporters inherits from another, and save_report has no idea which one it received. Hand it anything with an export(rows) method — a class you write next year, a stand-in used in tests, a class from someone else's library — and it works.

Built-in functions and operators are polymorphic too

You have been using polymorphism since your first lessons:

things = ["python", [1, 2, 3], {"a": 1, "b": 2}, (7, 8)]
for thing in things:
    print(type(thing).__name__, len(thing))

print(3 + 4)
print("3" + "4")
print([3] + [4])
print(3 * 4, "3" * 4, [3] * 4)

len() works on strings, lists, dictionaries and tuples. The + symbol adds numbers, glues strings and joins lists, while * multiplies numbers and repeats strings and lists. Each type supplies its own meaning for the same symbol through the dunder methods from the previous lesson. That is also why your own classes can join in: define __len__ or __add__ and the built-in syntax works on them.

Why not just check the type?

A tempting alternative is a chain of isinstance() checks. This is plain text on purpose, because it shows the style to avoid:

# every new payment class means editing this function
def pay_all(methods, amount):
    for method in methods:
        if isinstance(method, CreditCard):
            print("card:", method.pay(amount))
        elif isinstance(method, GiftVoucher):
            print("voucher:", method.pay(amount))
        # a new BankTransfer class would be silently ignored

# works for today's classes and for every future one
def pay_all(methods, amount):
    for method in methods:
        print(method.pay(amount))

The chain needs a new branch for each class, and a class you forget is ignored without any error. When the object knows how to do the job, the caller can just ask. Keep isinstance() for cases where the objects genuinely cannot decide for themselves, such as checking input at the edge of your program.

Look before you leap, or just try it

Sometimes you really do not know whether an object supports an operation. Python programmers have two idioms for that:

• LBYL, "look before you leap": check first with hasattr(obj, "send").
• EAFP, "easier to ask forgiveness than permission": call the method and handle AttributeError if it is missing.

class EmailSender:
    def send(self, text):
        return f"emailed: {text}"

class Pager:
    def send(self, text):
        return f"paged: {text}"

class Fax:
    pass          # no send() method

for device in [EmailSender(), Fax(), Pager()]:
    if hasattr(device, "send"):
        print(device.send("Server restarted"))
    else:
        print(type(device).__name__, "cannot send")

for device in [Fax(), Pager()]:
    try:
        print(device.send("Disk full"))
    except AttributeError:
        print(type(device).__name__, "has no send()")

Python programmers lean towards the second style, but keep the try block small. If send() itself contains a typo that raises AttributeError, a wide try/except reports "no send()" and hides the real bug.

The price of duck typing

Nobody checks the "contract" before the program runs. A misspelt method name or a different parameter list only shows up as an error when that line executes. So keep method names and parameters identical across your classes. When you want Python to enforce the contract up front, abstract base classes (a later lesson) can do that.