{"title":"Polymorphism","description":"","content":"Polymorphism is the idea that one piece of code can work with many different types as long as they behave the right way. A function that prints an order summary should not care whether the items are books, T-shirts, or downloadable apps; it should just ask each item for its price and shipping cost. This lesson covers what polymorphism means in Python, how duck typing makes it cheap to achieve, when `isinstance()` is the right tool and when it gets in the way, and the EAFP style that ties it all together.\n\n---\n\n# One Interface, Many Implementations\n\nPolymorphism literally means \"many shapes\". In code, it means writing one piece of logic that handles objects of different types as long as each type supports the same operations. The caller asks for a behavior; each type decides how to do it.\n\nPicture an online store with several kinds of products: physical books that ship in a box, T-shirts that need a different box size, and digital downloads that ship through the internet. Each one calculates shipping differently, but the checkout code shouldn't have to know that. It just wants a number.\n\n\n```python\nclass Book:\n def __init__(self, title, weight_kg):\n self.title = title\n self.weight_kg = weight_kg\n\n def calculate_shipping(self):\n return 2.00 + self.weight_kg * 1.50\n\nclass Tshirt:\n def __init__(self, design, size):\n self.design = design\n self.size = size\n\n def calculate_shipping(self):\n return 4.99\n\nclass DigitalDownload:\n def __init__(self, title):\n self.title = title\n\n def calculate_shipping(self):\n return 0.00\n\ncart = [\n Book(\"Clean Code\", 0.8),\n Tshirt(\"AlgoMaster Logo\", \"M\"),\n DigitalDownload(\"Python eBook\"),\n]\n\ntotal_shipping = sum(item.calculate_shipping() for item in cart)\nprint(f\"Total shipping: ${total_shipping:.2f}\")\n```\n\n\nNotice the `sum` expression. It loops over a list that mixes three completely different classes and calls `calculate_shipping()` on each one. The loop has no idea what type it's holding. It just relies on every item answering the same call. That is polymorphism in one sentence: the call site stays the same; the called code varies.\n\nThe opposite would be a checkout function that asks \"what kind of thing are you?\" and branches on the answer. We'll see that style later in this lesson, and we'll see why it ages badly the moment you add a fourth product type.\n\n\n```mermaid\nflowchart LR\n Cart[\"cart contains
Book, Tshirt,
DigitalDownload\"]:::cyan\n Loop[\"sum(item.calculate_shipping()
for item in cart)\"]:::orange\n Book[\"Book.calculate_shipping
weight-based\"]:::green\n Shirt[\"Tshirt.calculate_shipping
flat $4.99\"]:::green\n Digital[\"DigitalDownload.calculate_shipping
returns 0.00\"]:::green\n Total[\"Total shipping\"]:::teal\n\n Cart --> Loop\n Loop --> Book\n Loop --> Shirt\n Loop --> Digital\n Book --> Total\n Shirt --> Total\n Digital --> Total\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the shape every polymorphic design takes: one call site (orange) routes to one of several implementations (green) depending on the runtime type of the item, and the caller collects the results without caring which branch ran. Adding a fifth product type means writing one more class with a `calculate_shipping` method; the loop never changes.\n\n---\n\n# Duck Typing: If It Walks Like a Duck\n\nThe classic phrasing goes: \"If it walks like a duck and quacks like a duck, it's a duck.\" Python takes that seriously. It doesn't check whether an object's type sits in some hierarchy; it checks whether the object can do what you're asking. If you call `.calculate_shipping()` and the object responds with a number, Python doesn't care what class it came from.\n\nThis style is called **duck typing**, and it's the default way Python does polymorphism. There's no `interface` keyword you have to declare, no `implements` clause to add to a class. Two unrelated classes can both have a `calculate_shipping` method, and any code that needs that method will work with either one.\n\n\n```python\nclass Book:\n def calculate_shipping(self):\n return 3.50\n\nclass CoffeeMug:\n def calculate_shipping(self):\n return 5.99\n\nclass Subscription:\n \"\"\"An online subscription. Not a 'product' by any inheritance line.\"\"\"\n def calculate_shipping(self):\n return 0.00\n\ndef shipping_estimate(items):\n return sum(item.calculate_shipping() for item in items)\n\nprint(shipping_estimate([Book(), CoffeeMug(), Subscription()]))\n```\n\n\n`Book`, `CoffeeMug`, and `Subscription` share no parent class. They aren't related at all in the class hierarchy. But `shipping_estimate` works with all three because all three quack the right way. The \"interface\" here is implicit: it's the set of methods the caller actually calls. As long as an object has those methods, it fits.\n\nThe other side of this is that Python won't catch a missing method until you actually run the call. If you pass an object that doesn't have `calculate_shipping`, you get an `AttributeError` at the moment of the call, not at the moment of construction:\n\n\n```python\nclass StoreGiftCard:\n \"\"\"Oops, forgot to define calculate_shipping.\"\"\"\n pass\n\nshipping_estimate([Book(), StoreGiftCard()])\n```\n\n\nThat's the trade-off duck typing makes. You get flexibility (any class that fits the protocol works, no inheritance required) in exchange for losing static guarantees (a wrong type only shows up at call time). In practice, Python developers lean on tests and type hints to recover the safety, and most of the time it pays off.\n\n\n> **INFO**\n>\n> **Cost:** Duck typing fails late. If a missing method only matters in one rarely-hit branch, the bug can hide until production. Tests that exercise each polymorphic branch are the cheap fix.\n\n\n---\n\n# Method Overriding in Subclasses\n\nPolymorphism doesn't require inheritance, but inheritance is one of the most common ways to set it up. When a subclass defines a method with the same name as a parent's method, the subclass's version takes over for instances of the subclass. This is **method overriding**, and here we look at how it powers polymorphism.\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\n def calculate_shipping(self):\n return 4.99\n\nclass HeavyAppliance(Product):\n def __init__(self, name, price, weight_kg):\n super().__init__(name, price)\n self.weight_kg = weight_kg\n\n def calculate_shipping(self):\n return 9.99 + self.weight_kg * 0.50\n\nclass DigitalDownload(Product):\n def calculate_shipping(self):\n return 0.00\n\ncart = [\n Product(\"USB Cable\", 9.99),\n HeavyAppliance(\"Microwave\", 129.00, 12.0),\n DigitalDownload(\"Python eBook\", 19.99),\n]\n\nfor item in cart:\n print(f\"{item.name}: ${item.calculate_shipping():.2f}\")\n```\n\n\nThree different `calculate_shipping` methods get called inside the same loop. Python picks the right one for each object by looking at the object's actual class, not the class the variable was \"supposed\" to hold. That last point is the whole game: Python dispatches methods on the runtime type, not on any declared type.\n\nThere's no \"virtual\" keyword to flip, no special syntax to opt in. Every method in Python is overridable by default, and every method call goes through this dynamic lookup. If you've used languages where you have to mark methods as virtual or abstract to get this behavior, Python's approach can feel almost too easy. The cost is the one we already saw: a typo in a method name doesn't trip a compiler error, because there is no compiler in the usual sense.\n\n\n```mermaid\nflowchart LR\n Call[\"item.calculate_shipping()\"]:::cyan\n Lookup[\"look up method
on item's actual class\"]:::orange\n Product[\"Product.calculate_shipping
flat $4.99\"]:::green\n Heavy[\"HeavyAppliance.calculate_shipping
weight-based\"]:::green\n Digital[\"DigitalDownload.calculate_shipping
returns 0.00\"]:::green\n Result[\"return number\"]:::teal\n\n Call --> Lookup\n Lookup -->|type is Product| Product\n Lookup -->|type is HeavyAppliance| Heavy\n Lookup -->|type is DigitalDownload| Digital\n Product --> Result\n Heavy --> Result\n Digital --> Result\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram captures the runtime lookup: the call site asks for `calculate_shipping`, Python checks the object's actual class to find a definition, and the matching version runs. The decision happens fresh on every call, which is why swapping out the object swaps out the behavior with no extra ceremony.\n\n---\n\n# Inheritance Polymorphism vs Duck Typing\n\nBoth approaches give you polymorphism, but they reach it from different directions. Inheritance says \"these classes share a parent, so they share a method\". Duck typing says \"these classes share a method, that's all I need\". Python supports both and tends to prefer the second.\n\nCompare two versions of the same idea. First, an inheritance-based design where every product is a subclass of `Product`:\n\n\n```python\nclass Product:\n def calculate_shipping(self):\n raise NotImplementedError\n\nclass Book(Product):\n def calculate_shipping(self):\n return 3.50\n\nclass Tshirt(Product):\n def calculate_shipping(self):\n return 4.99\n\ndef total_shipping(products):\n return sum(p.calculate_shipping() for p in products)\n\nprint(total_shipping([Book(), Tshirt()]))\n```\n\n\nThis works. Every subclass overrides the placeholder method, and the function gets the right number. It's also explicit about the contract: anyone reading `Product` sees the method that subclasses are expected to define.\n\nNow the duck-typed version. Same outcome, no shared parent:\n\n\n```python\nclass Book:\n def calculate_shipping(self):\n return 3.50\n\nclass Tshirt:\n def calculate_shipping(self):\n return 4.99\n\ndef total_shipping(products):\n return sum(p.calculate_shipping() for p in products)\n\nprint(total_shipping([Book(), Tshirt()]))\n```\n\n\nIdentical result. `total_shipping` doesn't ask anything about the types; it just calls the method. Adding a `Subscription` class to the mix needs zero work in the existing code, no parent class to extend, no registry to update.\n\n\n| Approach | Pros | Cons |\n| --- | --- | --- |\n| Inheritance polymorphism | Explicit contract in the parent class; static checkers can verify the interface; shared default behavior is easy. | Forces a class hierarchy; classes from different libraries can't easily share an interface. |\n| Duck typing | No hierarchy needed; any class with the right methods fits; great for mixing types from unrelated libraries. | Contract is implicit; a missing method only shows up at call time. |\n\n\nPython developers generally reach for duck typing first and add a base class only when one of these is true: there's real shared code (not just a shared method name) that belongs in a parent, the contract is complex enough that writing it down helps, or you need `isinstance` checks for some external reason (covered in the next section). Abstract base classes formalize the \"write it down\" case.\n\nSaid plainly: in Python, the question \"do these objects share a parent?\" matters less than the question \"do these objects share the methods I need?\" The second question is the one most code actually has to answer.\n\n---\n\n# `isinstance()` and `issubclass()`\n\nPython gives you two builtins for type checking. `isinstance(obj, cls)` returns `True` if `obj` is an instance of `cls` (or any subclass). `issubclass(sub, parent)` returns `True` if `sub` is `parent` or a subclass of `parent`.\n\n\n```python\nclass Product:\n pass\n\nclass Book(Product):\n pass\n\nbook = Book()\n\nprint(isinstance(book, Book)) # True\nprint(isinstance(book, Product)) # True, because Book is a subclass\nprint(isinstance(book, str)) # False\n\nprint(issubclass(Book, Product)) # True\nprint(issubclass(Book, object)) # True, every class subclasses object\nprint(issubclass(Book, str)) # False\n```\n\n\nBoth functions accept a tuple as the second argument to test against several types at once: `isinstance(value, (int, float))` returns `True` if `value` is a number.\n\nThese tools have real uses. The two most common are:\n\n1. Reacting to truly different kinds of inputs at an API boundary, for example, accepting either a single product or a list of products and normalizing them.\n2. Friendly error messages or fast-path optimizations where knowing the concrete type matters.\n\n\n```python\ndef normalize_to_cart(items):\n \"\"\"Accept either a single item or a list of items; always return a list.\"\"\"\n if isinstance(items, list):\n return items\n return [items]\n\nprint(normalize_to_cart([\"A\", \"B\"]))\nprint(normalize_to_cart(\"Single\"))\n```\n\n\nThat's a legitimate use. The function genuinely needs to branch on the input's shape, and the branches are short and don't grow.\n\nThe misuse is dispatching on type to pick which method to call:\n\n\n```python\ndef calculate_shipping(item):\n if isinstance(item, Book):\n return 3.50\n elif isinstance(item, Tshirt):\n return 4.99\n elif isinstance(item, DigitalDownload):\n return 0.00\n else:\n raise TypeError(f\"Unknown product type: {type(item).__name__}\")\n```\n\n\nThis is the anti-pattern duck typing was designed to replace. The polymorphic version is what we wrote earlier: every product class has its own `calculate_shipping`, and the caller just calls it. The next section digs into why the `isinstance` chain hurts.\n\n\n> **INFO**\n>\n> **Cost:** `isinstance` is fast on its own (constant time after the class hierarchy is fixed), but a chain of `isinstance` checks is O(n) in the number of branches, and it grows every time someone adds a new type. Polymorphic dispatch is O(1) regardless of how many product types exist.\n\n\n---\n\n# Type-Based Dispatch vs Polymorphic Methods\n\nThe \"long chain of `isinstance` checks\" pattern shows up in almost every codebase that hasn't fully embraced polymorphism yet. It works at first, but it ages badly. Each time someone adds a new product type, they have to find every chain of checks and add another branch. Miss one, and the new type silently falls through to an error or, worse, the wrong default.\n\nHere's the type-dispatched version of a checkout function:\n\n\n```python\nclass Book:\n def __init__(self, title, weight_kg):\n self.title = title\n self.weight_kg = weight_kg\n\nclass Tshirt:\n def __init__(self, design):\n self.design = design\n\nclass DigitalDownload:\n def __init__(self, title):\n self.title = title\n\ndef calculate_shipping(item):\n if isinstance(item, Book):\n return 2.00 + item.weight_kg * 1.50\n elif isinstance(item, Tshirt):\n return 4.99\n elif isinstance(item, DigitalDownload):\n return 0.00\n raise TypeError(f\"Unknown item type: {type(item).__name__}\")\n\ncart = [Book(\"Clean Code\", 0.8), Tshirt(\"Logo\"), DigitalDownload(\"eBook\")]\nprint(sum(calculate_shipping(i) for i in cart))\n```\n\n\nNow imagine the team adds gift cards. Then subscription boxes. Then refurbished electronics. Each addition means hunting for every chain of `isinstance` checks across the codebase, adding a branch, hoping nothing was missed. The shipping function might have one chain. The tax function probably has another. The receipt printer has a third. The chains drift apart, and one day a new product type prints a correct shipping cost but the wrong tax line.\n\nThe polymorphic version puts each type's behavior on the type itself:\n\n\n```python\nclass Book:\n def __init__(self, title, weight_kg):\n self.title = title\n self.weight_kg = weight_kg\n\n def calculate_shipping(self):\n return 2.00 + self.weight_kg * 1.50\n\nclass Tshirt:\n def __init__(self, design):\n self.design = design\n\n def calculate_shipping(self):\n return 4.99\n\nclass DigitalDownload:\n def __init__(self, title):\n self.title = title\n\n def calculate_shipping(self):\n return 0.00\n\ncart = [Book(\"Clean Code\", 0.8), Tshirt(\"Logo\"), DigitalDownload(\"eBook\")]\nprint(sum(item.calculate_shipping() for item in cart))\n```\n\n\nSame answer, but the structure is different in an important way. Adding a gift card now means writing one class with one `calculate_shipping` method. No existing code changes. The caller's loop doesn't grow. The function isn't a list of `if`s waiting to forget the new case. The knowledge of \"how does this product calculate shipping?\" lives next to the data it depends on.\n\n\n| Pattern | Where the type knowledge lives | What happens when you add a new type |\n| --- | --- | --- |\n| Type-based dispatch (`isinstance` chain) | In every caller that branches on type | Edit every chain in the codebase; hope none are missed |\n| Polymorphic methods | On the type itself | Add one class with the method; callers unchanged |\n\n\nThe polymorphic version isn't always the right call. If the behavior really depends on two things at once (the product type and, say, the destination country), no single method can own the whole decision, and you may need a different pattern. But for the common case (one operation, behavior that varies by type) putting the method on the type is the cleaner default, and it's the path Python is built to support.\n\n---\n\n# EAFP vs LBYL\n\nTwo style names show up constantly in Python writing: **EAFP** (\"easier to ask forgiveness than permission\") and **LBYL** (\"look before you leap\"). They describe two ways to handle the question \"will this operation work?\" EAFP just tries the operation and catches the exception if it fails. LBYL checks first and only attempts the operation if the check passes.\n\nThese styles connect to polymorphism because they're the practical face of duck typing. If you're going to trust that an object has a `charge` method, the most Pythonic way to use it is to call the method and handle the failure if it isn't there, rather than checking ahead of time.\n\nCompare both styles for processing a payment:\n\n\n```python\nclass CreditCard:\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} to credit card\")\n return True\n\nclass PayPal:\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} via PayPal\")\n return True\n\nclass BankTransfer:\n def charge(self, amount):\n print(f\"Charging ${amount:.2f} via bank transfer\")\n return True\n\nclass StoreCredit:\n \"\"\"Doesn't support charging; you have to redeem it manually.\"\"\"\n pass\n```\n\n\nThe LBYL version checks before calling:\n\n\n```python\ndef process_payment_lbyl(method, amount):\n if hasattr(method, \"charge\"):\n return method.charge(amount)\n print(\"Payment method doesn't support charging\")\n return False\n\nprocess_payment_lbyl(CreditCard(), 49.99)\nprocess_payment_lbyl(StoreCredit(), 49.99)\n```\n\n\nThe EAFP version just tries and handles the failure:\n\n\n```python\ndef process_payment_eafp(method, amount):\n try:\n return method.charge(amount)\n except AttributeError:\n print(\"Payment method doesn't support charging\")\n return False\n\nprocess_payment_eafp(CreditCard(), 49.99)\nprocess_payment_eafp(StoreCredit(), 49.99)\n```\n\n\nSame outcome, different style. Python prefers EAFP for several reasons:\n\n- It plays well with duck typing. EAFP doesn't care what type the object is, only what it can do. The LBYL check has to know what to look for and can miss things (a property that raises on access, a `__getattr__` that lies about `hasattr`).\n- It avoids a race condition window. With LBYL, between the check and the call, something else could change the object's state. With EAFP, the check and the call are the same operation.\n- It's often faster on the happy path. The check costs something every call, the exception costs nothing unless it fires, and the happy path is usually most of the calls.\n\nThe simple \"does this file exist before I open it?\" example shows EAFP's case clearly:\n\n\n```python\n# LBYL: check first\nimport os\nif os.path.exists(\"orders.csv\"):\n with open(\"orders.csv\") as f:\n data = f.read()\nelse:\n data = \"\"\n```\n\n\nThat code has a bug. Between the `exists` check and the `open`, the file could be deleted, renamed, or have its permissions changed. The check passed, the open still fails.\n\n\n```python\n# EAFP: try, handle the failure\ntry:\n with open(\"orders.csv\") as f:\n data = f.read()\nexcept FileNotFoundError:\n data = \"\"\n```\n\n\nThe EAFP version has no race condition, no double work, and reads like the actual intent: \"read the file; if there isn't one, use an empty string.\"\n\n\n| Style | When to prefer |\n| --- | --- |\n| EAFP (try/except) | Duck typing, file/network operations, anywhere a check and an action could disagree, most Python code by default. |\n| LBYL (check first) | When the check is much cheaper than the operation, when failure is the common case, when you need to validate input before any side effects. |\n\n\nEAFP is Python's default for a reason: it matches the language's dynamic nature and avoids redundant checks. LBYL still has a place, but it should be a deliberate choice, not the reflex.\n\n\n> **INFO**\n>\n> **Cost:** Raising an exception is more expensive than not raising one, so EAFP loses its edge if the \"except\" branch is hit most of the time. Profile if you're in a hot loop where failures are common; in normal code, the difference is invisible.\n","pageType":"python"}

Polymorphism

Get Premium