{"title":"Method Overriding","description":"","content":"Method overriding is how a subclass replaces or extends a method it would otherwise inherit unchanged. This lesson covers how Python decides which method to call, the difference between replacing and extending behavior, the Liskov substitution principle as a guide for safe overrides, the special case of overriding `__init__` and dunder methods, and common pitfalls.\n\n---\n\n# The Dispatch Rule\n\nWhen a method is called on an instance, Python finds the most specific version of that method in the class hierarchy and runs it. The rule is the one shown earlier: walk from the instance's class up through its parents (and grandparents, and so on), and use the first matching method name. The walk stops at the first match; classes further up the chain are ignored for this call.\n\n\n```python\nclass Product:\n def display_price(self):\n return f\"${self.price:.2f}\"\n\nclass DiscountedProduct(Product):\n def display_price(self):\n return f\"${self.price:.2f} (on sale!)\"\n\nregular = Product()\nregular.price = 19.99\n\ndiscounted = DiscountedProduct()\ndiscounted.price = 19.99\n\nprint(regular.display_price())\nprint(discounted.display_price())\n```\n\n\nBoth objects have a `price` of `19.99`, but they're different classes. Python finds `display_price` on `Product` for the first object and on `DiscountedProduct` for the second. The override produces the different output; nothing about the call site changes.\n\nThis is called **dynamic dispatch** (also \"late binding\" in some textbooks). The decision about which method to run isn't made when the code is written; it's made when the call happens, based on the actual class of the object. Python looks up the method through the object's type, not through the variable name used to refer to it.\n\n\n```mermaid\nflowchart TD\n Call[\"regular.display_price()\"]:::cyan\n Step1[\"Check regular's class:
Product\"]:::orange\n Step2[\"Found display_price on Product\"]:::green\n Step3[\"Run Product.display_price\"]:::green\n\n Call2[\"discounted.display_price()\"]:::cyan\n Step1b[\"Check discounted's class:
DiscountedProduct\"]:::orange\n Step2b[\"Found display_price on
DiscountedProduct\"]:::green\n Step3b[\"Run DiscountedProduct.display_price
(walk stops here)\"]:::green\n\n Call --> Step1 --> Step2 --> Step3\n Call2 --> Step1b --> Step2b --> Step3b\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```\n\n\nThe two calls follow the same algorithm but find their match at different classes. The walk stops at the first definition; on the second call, Python never reaches `Product.display_price` because the subclass has its own.\n\nThe same dispatch happens when methods on the parent class call other methods. If `Product.format_label` calls `self.display_price()`, that call goes through the same dispatch and picks up `DiscountedProduct.display_price` for a discounted instance. The parent's code can call methods that the subclass has overridden, and the subclass's version is what runs.\n\nThis last point is what makes the **Template Method** pattern work. A parent class defines a method that orchestrates several steps; subclasses override individual steps without rewriting the orchestration.\n\n---\n\n# Replace vs Extend\n\nTwo common reasons to override a method. The first is **replacement**: the parent's version is wrong for this subclass, and the subclass needs to do something entirely different. The second is **extension**: the parent's version is right, but the subclass adds more work (before, after, or around the parent's logic).\n\nReplacement looks like writing a brand-new method that ignores the parent:\n\n\n```python\nclass PaymentMethod:\n def charge(self, amount):\n return f\"Charging ${amount:.2f} using generic payment\"\n\nclass CreditCard(PaymentMethod):\n def charge(self, amount):\n return f\"Charging ${amount:.2f} to card ending 4242\"\n\nclass GiftCard(PaymentMethod):\n def charge(self, amount):\n return f\"Deducting ${amount:.2f} from gift card balance\"\n\nfor method in [PaymentMethod(), CreditCard(), GiftCard()]:\n print(method.charge(50.00))\n```\n\n\n`CreditCard.charge` and `GiftCard.charge` don't call `super().charge(amount)`. They have nothing to extend; the parent's generic implementation is a placeholder, not something to build on. This is full replacement.\n\nExtension uses `super()` to run the parent's logic and adds to the result:\n\n\n```python\nclass Product:\n def describe(self):\n return f\"{self.name}: ${self.price:.2f}\"\n\nclass DiscountedProduct(Product):\n def __init__(self, name, price, discount_percent):\n self.name = name\n self.price = price\n self.discount_percent = discount_percent\n\n def describe(self):\n base = super().describe()\n return f\"{base} ({self.discount_percent}% off)\"\n\nitem = DiscountedProduct(\"Coffee Mug\", 12.99, 20)\nprint(item.describe())\n```\n\n\n`DiscountedProduct.describe` calls `super().describe()` to run `Product.describe`, then appends the discount tag. The override keeps the parent's format intact. If `Product.describe` ever changes (different currency formatting, added stock count), the override still produces sensible output because it doesn't duplicate any of the parent's logic.\n\nThe choice between replacement and extension is about whether the parent's logic is useful for this subclass.\n\n- If yes, extend (`super().method()` and add to its result).\n- If no, replace (write the whole new method without calling `super()`).\n- When in doubt, ask whether removing the parent's logic from the call would change the output. If it would, extension is needed; if not, replacement is fine.\n\nA third pattern, **wrapping**, has the subclass add work both before and after the parent's call:\n\n\n```python\nclass Logger:\n def log(self, message):\n print(f\"[LOG] {message}\")\n\nclass TimestampedLogger(Logger):\n def log(self, message):\n import time\n timestamp = time.strftime(\"%H:%M:%S\")\n print(f\"--- {timestamp} ---\")\n super().log(message)\n print(f\"--- end ---\")\n\nTimestampedLogger().log(\"hello\")\n```\n\n\nThe override runs code, calls `super()`, then runs more code. The before/after work bookends the parent's logic. The pattern is useful for cross-cutting concerns like logging, timing, or error handling.\n\n---\n\n# Liskov Substitution: Don't Break the Contract\n\nOverriding is a sharp tool. It lets behavior change, but the change has to stay compatible with what callers of the parent class expect. The Liskov substitution principle, introduced in the single-inheritance lesson, matters most here.\n\nThe principle, stated briefly: anywhere code expects a parent instance, an instance of any subclass should work without surprises. In practical terms, an override:\n\n- Should return the same kind of value the parent promised. If `Product.describe` returns a string, `DiscountedProduct.describe` must also return a string, not a dictionary or `None`.\n- Should not raise exceptions the parent didn't declare. If the parent's `charge` never raises an error for valid amounts, the override shouldn't raise either.\n- Should not require more from its inputs than the parent did. If the parent accepts any positive number, the override shouldn't reject odd numbers (that would be a stronger precondition).\n- Should not guarantee less than the parent. If the parent promised the item was saved to the database before returning, the override shouldn't return before the save completes.\n\nThe following violation runs without errors but breaks calling code:\n\n\n```python\nclass Account:\n def __init__(self, balance):\n self.balance = balance\n\n def withdraw(self, amount):\n if amount > self.balance:\n raise ValueError(\"Insufficient funds\")\n self.balance -= amount\n return self.balance\n\nclass OverdraftAccount(Account):\n def withdraw(self, amount):\n # \"Overdraft is allowed\", but now any negative balance is fine\n self.balance -= amount\n return self.balance\n\ndef transfer(source, target, amount):\n source.withdraw(amount)\n target.balance += amount\n\nregular = Account(balance=100)\noverdraft = OverdraftAccount(balance=100)\n\ntransfer(regular, overdraft, 50) # works\ntransfer(overdraft, regular, 200) # overdraft.balance goes to -150 silently\nprint(regular.balance, overdraft.balance)\n```\n\n\n`OverdraftAccount.withdraw` substitutes for `Account.withdraw` in a way the caller of `transfer` couldn't anticipate. The parent guarantees that a successful return means the balance wasn't overdrawn; the subclass allows negative balances without signaling. Any auditing code, reporting code, or downstream logic that relied on the parent's guarantee produces wrong results without warning.\n\nThe fix is either to make the subclass honor the contract (raise a different exception when overdraft limits are hit, instead of allowing arbitrary negative balances), or to recognize that `OverdraftAccount` isn't a kind of `Account` in the strict sense and shouldn't inherit from it.\n\nLiskov doesn't need to be memorized as a formal rule. The intuition is enough: if the override would surprise code calling the parent's interface, the contract is broken.\n\n---\n\n# Calling the Parent: `super().method()`\n\nThe mechanics of `super()` are the same as in the inheritance basics lesson, but the patterns are worth restating because overriding is where `super()` matters most.\n\nThe simplest pattern is \"run the parent's version, then add to its result\":\n\n\n```python\nclass Product:\n def label(self):\n return f\"[{self.product_id}] {self.name}\"\n\nclass FlashDealProduct(Product):\n def label(self):\n return super().label() + \" - FLASH SALE!\"\n\nflash = FlashDealProduct()\nflash.product_id = 101\nflash.name = \"Coffee Mug\"\nprint(flash.label())\n```\n\n\n`super()` here is a shorthand. The full form is `super(FlashDealProduct, self)`, but Python 3 allows `super()` without arguments inside any method and figures out the rest from context.\n\nA second pattern is \"wrap the parent\": run code, call `super()`, run more code. The `TimestampedLogger` example earlier showed this. It's the same idea as decorators applied to methods, expressed through inheritance.\n\nA third pattern is \"delegate conditionally\": call `super()` only in some cases. The pattern fits when the override sometimes wants the parent's behavior and sometimes doesn't:\n\n\n```python\nclass CartItem:\n def total(self):\n return self.price * self.quantity\n\nclass BuyOneGetOneFreeItem(CartItem):\n def total(self):\n if self.quantity <= 1:\n return super().total()\n # Charge for half the items, rounded up\n chargeable = (self.quantity + 1) // 2\n return self.price * chargeable\n\nitem = BuyOneGetOneFreeItem()\nitem.price = 10.00\nitem.quantity = 1\nprint(f\"qty 1: ${item.total():.2f}\")\nitem.quantity = 2\nprint(f\"qty 2: ${item.total():.2f}\")\nitem.quantity = 3\nprint(f\"qty 3: ${item.total():.2f}\")\n```\n\n\nFor one item, the subclass falls back to the parent's calculation. For more, it applies its own discount logic. The override picks when to defer and when to take over, instead of always doing one or the other.\n\n`super().method()` is one extra function call per level. The overhead is negligible for normal use. In hot loops where every fraction of a microsecond matters, profile first before optimizing.\n\n---\n\n# Template Method: An Override-Friendly Pattern\n\nA common pattern built on top of method overriding is the **Template Method** pattern. The parent class defines a method that lays out the overall flow of an operation, calling smaller methods at each step. Subclasses override only the small steps they care about and inherit the rest. The overall flow stays consistent across all subclasses, and each subclass customizes the pieces that differ.\n\n\n```python\nclass ReportGenerator:\n def generate(self, data):\n rows = self.collect_rows(data)\n formatted = self.format_rows(rows)\n return self.wrap_output(formatted)\n\n def collect_rows(self, data):\n return list(data)\n\n def format_rows(self, rows):\n return \"\\n\".join(str(row) for row in rows)\n\n def wrap_output(self, body):\n return f\"Report:\\n{body}\"\n\nclass CsvReport(ReportGenerator):\n def format_rows(self, rows):\n return \"\\n\".join(\",\".join(str(field) for field in row) for row in rows)\n\n def wrap_output(self, body):\n return body # CSV needs no decoration\n\nclass HtmlReport(ReportGenerator):\n def format_rows(self, rows):\n items = \"\".join(f\"

{row}

\" for row in rows)\n return f\"

{items}\"\n\n def wrap_output(self, body):\n return f\"{body}\"\n\ndata = [(\"Alice\", 30), (\"Bob\", 25)]\n\nprint(ReportGenerator().generate(data))\nprint()\nprint(CsvReport().generate(data))\nprint()\nprint(HtmlReport().generate(data))\n```\n\n\n`ReportGenerator.generate` is the template. It always does the same three steps in the same order: collect rows, format them, wrap the result. The subclasses don't override `generate` at all. Each one customizes the two steps that differ for its output format, and the orchestration stays untouched.\n\nThis is the dispatch rule (from earlier) doing useful work. When `generate` calls `self.format_rows(rows)`, dispatch picks the right override for whichever subclass the instance belongs to. `CsvReport().generate(data)` runs `ReportGenerator.generate`, which calls `self.format_rows` and gets `CsvReport.format_rows`. The parent doesn't need to know what subclasses exist; it calls through `self` and lets dispatch sort it out.\n\nThe methods the parent calls are sometimes called **hook methods**: places where subclasses are expected to plug in their customization. A well-designed template documents which methods are hooks (intended to be overridden) and which are part of the orchestration (not meant to be touched). Without that documentation, the structure has to be reconstructed by tracing through the code.\n\n---\n\n# Overriding `__init__`\n\n`__init__` is the method most commonly overridden, and the rules around it are worth restating because the consequences of getting them wrong are visible right away.\n\nThe key facts:\n\n1. The subclass's `__init__` replaces the parent's entirely. Python doesn't call the parent's `__init__` automatically when both classes have one.\n2. To run the parent's setup, the subclass must call `super().__init__(...)` with whatever arguments the parent expects.\n3. By convention, `super().__init__(...)` is called at the top of the subclass's `__init__`, before any subclass-specific work. This ensures parent attributes exist before the subclass touches anything.\n\nA correct subclass `__init__`:\n\n\n```python\nclass Order:\n def __init__(self, order_id, customer):\n self.order_id = order_id\n self.customer = customer\n self.items = []\n\nclass GiftOrder(Order):\n def __init__(self, order_id, customer, recipient_name, gift_message):\n super().__init__(order_id, customer)\n self.recipient_name = recipient_name\n self.gift_message = gift_message\n\ngift = GiftOrder(\n order_id=1,\n customer=\"Alice\",\n recipient_name=\"Bob\",\n gift_message=\"Happy birthday!\",\n)\n\nprint(gift.order_id, gift.customer, gift.items, gift.recipient_name)\n```\n\n\n`GiftOrder.__init__` first runs `super().__init__(order_id, customer)` so that `order_id`, `customer`, and `items` are set by `Order.__init__`. Then it adds the gift-specific attributes. Order matters: accessing `self.items` before `super().__init__(...)` would raise `AttributeError` because the attribute wouldn't exist yet.\n\nA common variation is to fix some of the parent's arguments and not expose them to the subclass's caller:\n\n\n```python\nclass DigitalOrder(Order):\n def __init__(self, order_id, customer, download_url):\n super().__init__(order_id, customer)\n # No physical shipping for digital orders, but we still inherit items\n self.download_url = download_url\n self.shipping_address = None # explicitly None for clarity\n```\n\n\nThe subclass doesn't have to pass through every parent argument unchanged. It can hard-code defaults or set fields the parent left out. The only requirement is that whatever the parent's `__init__` needs has to come from somewhere.\n\nConsider this broken code:\n\n\n```python\nclass Customer:\n def __init__(self, name, email):\n self.name = name\n self.email = email\n\nclass PremiumCustomer(Customer):\n def __init__(self, name, email, tier):\n self.tier = tier # bug: super() not called, so name/email never set\n\nbob = PremiumCustomer(\"Bob\", \"bob@example.com\", \"gold\")\nprint(bob.tier)\nprint(bob.name)\n```\n\n\nThe override omitted `super().__init__(name, email)`, so `Customer.__init__` never ran. `bob.tier` works because the override did set that. `bob.name` fails because nothing set it. The fix is the standard pattern:\n\n\n```python\nclass PremiumCustomer(Customer):\n def __init__(self, name, email, tier):\n super().__init__(name, email)\n self.tier = tier\n```\n\n\nThis bug is a frequent mistake when overriding `__init__`. It's easy to spot once recognized, but it doesn't fail until something tries to read a missing attribute, which can be far from the actual `__init__` definition.\n\n---\n\n# Overriding Dunder Methods\n\nDunder (double-underscore) methods are how classes integrate with Python's operators and builtins. Overriding them is how objects behave correctly with `==`, `+`, `len()`, `print()`, and others. The rules for overriding dunder methods differ a bit because Python itself calls them, not user code, so the contract has to be tight.\n\nA common override is `__eq__`, which controls what `==` means for the class. The default (inherited from `object`) compares object identity, which is rarely the right behavior for value-like classes:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\na = Product(101, \"Mug\")\nb = Product(101, \"Mug\")\nprint(a == b) # False by default; comparing object identity\n```\n\n\nTwo `Product` instances with the same data still compare as unequal because `object.__eq__` compares whether they're the same object in memory. Overriding `__eq__` defines equality by content:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n if not isinstance(other, Product):\n return NotImplemented\n return self.product_id == other.product_id\n\na = Product(101, \"Mug\")\nb = Product(101, \"Coffee Mug\") # different name, same id\nc = Product(202, \"Mug\")\nprint(a == b)\nprint(a == c)\n```\n\n\nA few important details about overriding `__eq__`:\n\n1. **Check the type of `other`.** The override should handle the case where `other` isn't a `Product` at all. Returning `NotImplemented` (a special builtin singleton) tells Python \"comparison undefined here; try the other operand's `__eq__`\". Returning `False` would say \"they're definitely unequal\", which is a stronger claim and can interact badly with other comparisons.\n2. **Override `__hash__` if `__eq__` is overridden.** Python uses `__hash__` for set membership and dict keys, and the contract is that equal objects must hash to the same value. Overriding `__eq__` alone causes Python to set `__hash__` to `None`, making instances unhashable (they can't be put in sets or used as dict keys). The fix is usually to override `__hash__` to return a hash of the same fields compared in `__eq__`.\n\n\n```python\nclass Product:\n def __init__(self, product_id, name):\n self.product_id = product_id\n self.name = name\n\n def __eq__(self, other):\n if not isinstance(other, Product):\n return NotImplemented\n return self.product_id == other.product_id\n\n def __hash__(self):\n return hash(self.product_id)\n\nproducts = {Product(101, \"Mug\"), Product(101, \"Coffee Mug\"), Product(202, \"Pen\")}\nprint(len(products))\n```\n\n\nTwo of the three products are considered equal (same `product_id`), so the set keeps only one of them and the pen, giving a size of two.\n\nOther dunders that often get overridden:\n\n\n| Dunder | Called by | Purpose |\n| --- | --- | --- |\n| `__str__` | `str()`, `print()` | Human-readable string representation |\n| `__repr__` | `repr()`, REPL display | Unambiguous representation for debugging |\n| `__eq__` | `==` | Equality comparison |\n| `__hash__` | `hash()`, set/dict keys | Integer hash for use in hash-based containers |\n| `__lt__`, `__le__`, etc. | `<`, `<=`, sorting | Ordering comparisons |\n| `__len__` | `len()` | Object's \"size\" |\n| `__iter__` | `for`, list comprehensions | Iteration |\n| `__contains__` | `in` | Membership testing |\n\n\nEach of these has a specific contract Python expects. Overriding them is how classes become first-class participants in the language. The course has a separate dunder methods chapter that goes deeper; the relevant point for overriding is that dunder methods are still methods, and the same dispatch rule applies. A subclass can override `__eq__` to provide a more specific notion of equality, like any other method.\n\n---\n\n# Pitfalls and Common Mistakes\n\nA few patterns to watch for when overriding methods.\n\n**Changing the signature.** If the parent's method is `def save(self, validate=True):` and the subclass overrides it as `def save(self):`, calls that pass `validate=False` to the parent's interface fail on subclass instances. The override has narrowed the API by accident. Subclasses should accept at least everything the parent accepted, even if they ignore some of it.\n\n\n```python\nclass Document:\n def save(self, validate=True):\n if validate:\n self._validate()\n print(\"saved\")\n\nclass DraftDocument(Document):\n def save(self): # bug: removed the validate parameter\n print(\"saved as draft\")\n\nDocument().save(validate=False) # works\nDraftDocument().save(validate=False) # TypeError: unexpected argument\n```\n\n\nThe fix is to accept the same parameters, even if the override doesn't use them:\n\n\n```python\nclass DraftDocument(Document):\n def save(self, validate=True):\n print(\"saved as draft\")\n```\n\n\n**Returning a different type.** Callers of the parent's method have built expectations around its return type. Changing it in the override breaks every assumption built on top. If the parent returns a `dict`, the override should return a `dict` (or a subclass of `dict`), not a `list` or `None`.\n\n**Calling `self.method()` instead of `super().method()`.** Inside an override, `self.method(...)` calls the method through dispatch, which finds the override itself, causing infinite recursion. To call the parent's version explicitly, use `super().method(...)`.\n\n\n```python\nclass A:\n def label(self):\n return \"A\"\n\nclass B(A):\n def label(self):\n # bug: self.label() calls B.label() (recursion)\n return self.label() + \" from B\"\n```\n\n\nThe correct version:\n\n\n```python\nclass B(A):\n def label(self):\n return super().label() + \" from B\"\n```\n\n\n**Forgetting that the parent's code might call the overridden method.** As shown in the Template Method section, if the parent's code calls `self.format_rows(...)` and the subclass overrides `format_rows`, the override is what runs. This is usually the goal, but it can also surprise code that didn't expect the parent to call into the override. Read the parent class to see which of its methods call other methods on `self`, especially when those other methods are being overridden.\n\n**Overriding a method by accident.** A method on a subclass with the same name as something a parent already defined (even when unintended) shadows the parent. This is most painful when the parent is `object` or a builtin like `list`: subclasses of `list` that define a method called `index` or `pop` are shadowing the list's own without warning. Use a name that doesn't conflict, or confirm the override is intentional.\n\nThe pattern across all of these is the same: an override changes how a method behaves, and other code (the parent's own code, the language runtime, callers) might depend on the original behavior in ways that aren't obvious from a single file. Treat overrides as contracts being modified, not as new methods being freely written.","pageType":"python"}

Method Overriding

Get Premium