{"title":"super() Function","description":"","content":"`super()` is the builtin used to call a parent class's methods from inside a subclass. It appears most often in `__init__` chains, in extended overrides that keep the parent's behavior, and in any class that participates in cooperative multiple inheritance. A lot of subtle behavior is packed into it: how the zero-argument form figures out the right class without help, why it uses the MRO instead of a fixed parent reference, and what goes wrong when you swap it out for a direct parent call. This chapter covers all of that.\n\n---\n\n# What `super()` Does\n\n`super()` returns a proxy object. The proxy lets you call methods as if you were a parent class, but with the current instance still bound to `self`. When you write `super().method(args)`, Python finds the next class after the current one in the instance's MRO, looks up `method` on that class, and calls it with the current `self`. The instance is the same, the data is the same, only the method lookup starts higher up the chain.\n\nA minimal example:\n\n\n```python\nclass Product:\n def describe(self):\n return \"a product\"\n\nclass DigitalProduct(Product):\n def describe(self):\n base = super().describe()\n return f\"digital, {base}\"\n\nprint(DigitalProduct().describe())\n```\n\n\nInside `DigitalProduct.describe`, `super()` returns a proxy bound to the current instance and pointing to the next class in the MRO, which is `Product`. `super().describe()` calls `Product.describe(self)` and returns its string. The override prepends `\"digital, \"` and returns the combined result.\n\nTwo points matter here. First, `super()` always carries the current `self` along, so attributes set on the instance by either class are visible to both. Second, `super()` doesn't search for \"a parent that happens to define this method\"; it walks the MRO one step at a time. If the next class in the MRO doesn't define the method, the lookup continues to the class after that, and so on, until it finds a match or runs off the end and raises `AttributeError`.\n\n---\n\n# The Zero-Argument Form vs. the Older Two-Argument Form\n\nIn modern Python, you write `super()` with no arguments. Inside any regular method of a class, that bare call returns the right proxy without further input. The compiler captures the class the method belongs to and the first argument (`self`), and passes them to `super` for you.\n\nBefore Python 3, the equivalent was the two-argument form: `super(DigitalProduct, self)`. You named the current class explicitly and passed `self`. Both forms do the same thing, and the two-argument form still works in Python 3:\n\n\n```python\nclass Product:\n def describe(self):\n return \"a product\"\n\nclass DigitalProduct(Product):\n def describe(self):\n # Old form: works but rarely needed.\n base = super(DigitalProduct, self).describe()\n return f\"digital, {base}\"\n\nprint(DigitalProduct().describe())\n```\n\n\nThe zero-argument form is cleaner, safer, and the default choice. It avoids two specific bugs that the two-argument form invites:\n\n- If you rename the class later, every `super(OldName, self)` call inside it must be updated, or methods on the wrong class get called without warning. The zero-argument form needs no edits.\n- If you copy-paste a method from one class to another, the hard-coded class name comes along with it. The pasted method calls methods on the original class, not the one it now lives in. The zero-argument form picks up the new class automatically.\n\nThe two-argument form still has narrow uses. Inside a function that isn't a method (a module-level helper called from somewhere), there's no implicit class to capture, so it must be named. Inside class methods (`@classmethod`), the form is `super(Cls, cls)`, and even there the zero-argument form usually works. In practice, `super()` is almost always the form used and the older syntax can be forgotten.\n\n---\n\n# `super()` Uses the MRO, Not \"the Parent\"\n\nIn single inheritance, `super()` and \"the parent class\" mean the same thing, so the distinction doesn't matter. In multiple inheritance, they diverge, and confusing the two is a common cause of broken cooperative hierarchies.\n\n`super()` returns a proxy that walks the **method resolution order** of the instance, not the source-code parent list. The \"next class\" depends on the type of the actual object, not on where the method is written.\n\nA diamond example shows the difference:\n\n\n```python\nclass Product:\n def describe(self):\n return \"product\"\n\nclass DigitalProduct(Product):\n def describe(self):\n return f\"digital, {super().describe()}\"\n\nclass DiscountableProduct(Product):\n def describe(self):\n return f\"discountable, {super().describe()}\"\n\nclass Ebook(DigitalProduct, DiscountableProduct):\n pass\n\n# Case 1: a plain DigitalProduct instance.\nprint(DigitalProduct().describe())\n\n# Case 2: an Ebook instance, where the MRO inserts DiscountableProduct.\nprint(Ebook().describe())\n```\n\n\nConsider `DigitalProduct.describe`. The method itself doesn't change between the two cases, but `super().describe()` resolves differently. For a `DigitalProduct` instance, the MRO is `DigitalProduct, Product, object`, so `super()` points to `Product`. For an `Ebook` instance, the MRO is `Ebook, DigitalProduct, DiscountableProduct, Product, object`, so `super()` from inside `DigitalProduct.describe` points to `DiscountableProduct`, not `Product`.\n\nThis is the practical difference. `super()` doesn't have an opinion about which class is \"the parent\". It walks the MRO and uses whatever comes next. The same method can deliver `super()` calls to different classes depending on the instance type, which is what cooperative multiple inheritance needs.\n\nThe MRO is set at class-definition time. The `super()` call uses the instance type at runtime. The two come together at the call site: `super()` reads the MRO of `type(self)` and finds the next class after the one the current method lives in.\n\nInside a method, the resolution target of `super()` can be read from `type(self).__mro__`. Compare that list with the class the method is defined on, and the next entry in the list is what `super()` points to.\n\n---\n\n# `super().__init__(...)` in Subclass Init\n\nThe most common use of `super()` is in a subclass's `__init__` to run the parent's initialization. Without that call, the parent never gets to set up its own attributes, and the subclass starts life with a half-initialized instance.\n\nA small order hierarchy makes the pattern concrete:\n\n\n```python\nclass Order:\n def __init__(self, order_id, total):\n self.order_id = order_id\n self.total = total\n\nclass GiftOrder(Order):\n def __init__(self, order_id, total, recipient):\n super().__init__(order_id, total)\n self.recipient = recipient\n\n def summary(self):\n return f\"Order #{self.order_id}: ${self.total:.2f} (gift for {self.recipient})\"\n\ngift = GiftOrder(101, 49.99, \"Alice\")\nprint(gift.summary())\n```\n\n\n`GiftOrder.__init__` calls `super().__init__(order_id, total)` first. That runs `Order.__init__`, which sets `self.order_id` and `self.total`. Then the subclass adds `self.recipient`. All three attributes end up on the same instance because both `__init__` calls receive the same `self`.\n\nTwo conventions matter here:\n\n- **Call `super().__init__(...)` before setting subclass-specific attributes.** The parent's setup can put the instance into a known state, including computing values the subclass might want to use. The other order isn't always wrong, but this is the convention readers expect.\n- **Forward arguments cleanly.** The parent's `__init__` decides what arguments it needs. The subclass takes care of any extras and forwards the rest. Don't redefine parameters on the subclass to pass them through unchanged; let them flow.\n\nThe wrong pattern is to skip `super()` and retype the parent's setup:\n\n\n```python\nclass GiftOrder(Order):\n def __init__(self, order_id, total, recipient):\n # Wrong: duplicates the parent's logic instead of calling it.\n self.order_id = order_id\n self.total = total\n self.recipient = recipient\n```\n\n\nThis works for trivial cases, but it drifts out of sync without warning. If `Order.__init__` adds validation, a computed attribute, or a default value, the subclass loses the new behavior. `super().__init__(...)` is what keeps the subclass in step with the parent.\n\nThe other broken pattern is forgetting to call `super().__init__` at all:\n\n\n```python\nclass GiftOrder(Order):\n def __init__(self, order_id, total, recipient):\n self.recipient = recipient\n # Bug: parent's __init__ never runs, so order_id and total don't exist.\n\ngift = GiftOrder(101, 49.99, \"Alice\")\nprint(gift.summary())\n```\n\n\nPython does not call the parent's `__init__` automatically when the subclass defines its own. The fix is to add `super().__init__(order_id, total)` before any subclass-specific work.\n\n---\n\n# Cooperative `super()` in Multiple Inheritance\n\nCooperative `super()` is the pattern where every class in an inheritance chain calls `super()` for the same method, and each class forwards the call along the MRO. The result is that a single call from the bottom of the hierarchy reaches every class once, in MRO order, instead of stopping at the first parent.\n\nCooperative `super()` is the reason multiple inheritance works at all in Python. The MRO gives the search order; cooperative `super()` is the agreement among classes to follow it.\n\nTwo rules make it work:\n\n1. **Every class in the chain must call `super().method(...)`** for the method, including classes at the top of the diamond if the chain needs to walk through them.\n2. **Signatures must agree, or use `*args, **kwargs` to forward.** If one class takes `verbose=False` and another doesn't, the call breaks unless the participating classes use `**kwargs` to pass through arguments they don't recognize.\n\nA cooperative `__init__` chain illustrates both rules:\n\n\n```python\nclass Product:\n def __init__(self, name, price, **kwargs):\n super().__init__(**kwargs)\n self.name = name\n self.price = price\n\nclass TaxableMixin:\n def __init__(self, *, tax_rate=0.08, **kwargs):\n super().__init__(**kwargs)\n self.tax_rate = tax_rate\n\nclass ShippableMixin:\n def __init__(self, *, weight_kg=1.0, **kwargs):\n super().__init__(**kwargs)\n self.weight_kg = weight_kg\n\nclass Laptop(Product, TaxableMixin, ShippableMixin):\n pass\n\nlaptop = Laptop(name=\"ThinkPad\", price=899.00, tax_rate=0.07, weight_kg=1.4)\nprint(laptop.name, laptop.price, laptop.tax_rate, laptop.weight_kg)\n```\n\n\nEach class takes the keyword arguments it cares about (using keyword-only syntax with `*`), then forwards the rest with `**kwargs`. The `super().__init__(**kwargs)` call sends the leftover arguments along the MRO. The chain ends at `object.__init__`, which accepts no extra arguments, so every keyword must be consumed by the time the call reaches `object`.\n\nThink of each `__init__` as a station along a track. Arguments enter at the bottom (the `Laptop` call), and each station takes its passengers (its own keyword arguments) and forwards the rest down the line. If one station forgets to forward, everyone after it gets stranded.\n\nThe same shape works for any cooperative method, not only `__init__`. If three classes all contribute to a `validate` method or a `to_dict` method, each one calls `super().validate(...)` or `super().to_dict()` and adds its own piece.\n\n\n```python\nclass Product:\n def to_dict(self):\n return {\"name\": self.name, \"price\": self.price}\n\nclass TaxableProduct(Product):\n def to_dict(self):\n data = super().to_dict()\n data[\"tax_rate\"] = self.tax_rate\n return data\n\nclass ShippableProduct(Product):\n def to_dict(self):\n data = super().to_dict()\n data[\"weight_kg\"] = self.weight_kg\n return data\n\nclass Phone(TaxableProduct, ShippableProduct):\n def __init__(self, name, price, tax_rate, weight_kg):\n self.name = name\n self.price = price\n self.tax_rate = tax_rate\n self.weight_kg = weight_kg\n\nprint(Phone(\"Pixel\", 699.0, 0.08, 0.187).to_dict())\n```\n\n\nEach `to_dict` calls `super().to_dict()` to get the dictionary built so far, then adds its own field. The MRO of `Phone` is `Phone, TaxableProduct, ShippableProduct, Product, object`, so the call walks through `TaxableProduct.to_dict`, `ShippableProduct.to_dict`, and `Product.to_dict` in that order. Each class contributes one key to the dictionary, and the result is the combined view.\n\nCooperative `super()` adds one Python call per class in the MRO. For a three- or four-class chain, the overhead is negligible. Deep cooperative chains (eight or more classes) can show up in profiles, but few hierarchies are that deep.\n\n---\n\n# Bound vs. Unbound `super()`\n\nIn Python 3, `super()` is always bound. The proxy returned by `super()` inside a method carries both the class and the instance, so `super().method(args)` passes `self` automatically. The form `super().method(self, args)` is not used; the `self` is implicit, like any normal method call.\n\nThe \"unbound\" form involves the two-argument syntax outside a method, or omitting the `self` argument. The two-argument form has variants:\n\n- `super(Cls, instance)` returns a proxy bound to `instance`. Calling methods on it passes `instance` automatically. This form matches the zero-argument `super()` inside a method.\n- `super(Cls, subclass)` (where `subclass` is a class, not an instance) returns a proxy useful for `@classmethod`s. It binds to the subclass instead of an instance.\n- `super(Cls)` with one argument returns an unbound proxy. It would have to be invoked on a specific instance later, which is uncommon.\n\nThe zero-argument form is used inside instance methods and the rest can be ignored. One situation where the two-argument form appears is inside a `@classmethod` that calls a parent class method:\n\n\n```python\nclass Product:\n @classmethod\n def from_dict(cls, data):\n return cls(data[\"name\"], data[\"price\"])\n\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nclass DigitalProduct(Product):\n @classmethod\n def from_dict(cls, data):\n # super() works inside classmethods too in Python 3.\n product = super().from_dict(data)\n product.is_digital = True\n return product\n\n def __init__(self, name, price, is_digital=False):\n super().__init__(name, price)\n self.is_digital = is_digital\n\np = DigitalProduct.from_dict({\"name\": \"Ebook\", \"price\": 19.99})\nprint(p.name, p.price, p.is_digital)\n```\n\n\nInside a classmethod, `super()` still works without arguments. It returns a proxy that uses `cls` instead of `self`, and methods called on it receive `cls` as their first argument. The same zero-argument call adapts to the kind of method it's used in.\n\nFor instance methods, the bound form applies. The proxy keeps `self` attached, no explicit pass is needed, and the method on the next class in the MRO runs as if it were called normally. The rule is simple: use `super()` with no arguments inside methods, and pass the same arguments as the method being forwarded to.\n\n---\n\n# Common Pitfalls\n\n`super()` is small, but it has a handful of failure modes. Most come from mixing cooperative `super()` with hard-coded parent calls, or from forgetting that `super()` walks the MRO instead of going to the literal source-code parent.\n\n**Forgetting to call `super().__init__()`.** Covered above. The fix is to add the call at the top of the subclass `__init__`. Watch for it when copying an existing subclass and changing its parent: a `super()` call that was correct in the original might need different arguments in the new version.\n\n**Replacing `super()` with `Parent.method(self)`.** Both forms can call a parent's method. In single inheritance, the difference is invisible. In multiple inheritance, the explicit call skips part of the MRO and breaks cooperation. Use `super()` unless there is a specific reason to bypass the MRO.\n\n\n```python\nclass Product:\n def describe(self):\n return \"product\"\n\nclass TaxableMixin(Product):\n def describe(self):\n return \"taxable, \" + super().describe()\n\nclass GiftWrappableMixin(Product):\n def describe(self):\n # Bug: hard-coded Product.describe(self) skips other classes in the MRO.\n return \"gift-wrappable, \" + Product.describe(self)\n\nclass Book(TaxableMixin, GiftWrappableMixin):\n pass\n\nprint(Book().describe())\n```\n\n\nFor this particular MRO, the output happens to look right, but the chain is fragile. Adding a new mixin between `GiftWrappableMixin` and `Product` means the hard-coded `Product.describe(self)` call still jumps straight to `Product` and skips the new class. The same code with `super()` would adapt automatically.\n\n**Mixing cooperative and non-cooperative classes.** If half the classes call `super()` and the other half don't, the chain breaks at the boundary. The output is partial: classes before the non-cooperative one ran, classes after it didn't. The fix is consistency. Either every class in a cooperative chain participates, or none do.\n\n**Signature mismatches.** If one class's `__init__` accepts `weight_kg` and another's accepts `tax_rate`, and neither uses `**kwargs` to forward, the chain throws `TypeError` when called. The fix is to use `**kwargs` in every cooperative `__init__` and let each class take only the arguments it cares about, as in the cooperative example above.\n\n**Calling `super()` outside a method.** The zero-argument form needs an enclosing method to capture the class and `self`. A call to `super()` from a regular function (or a nested function inside a method) raises `RuntimeError: super(): no arguments`. The fix is to move the call back inside a method or use the two-argument form with the class and instance named explicitly.\n\nA small example of the signature mismatch:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nclass TaxableMixin:\n def __init__(self, tax_rate):\n self.tax_rate = tax_rate\n\nclass TaxableProduct(TaxableMixin, Product):\n pass\n\n# This breaks: TaxableMixin.__init__ doesn't accept name/price.\nTaxableProduct(name=\"Book\", price=10.0, tax_rate=0.08)\n```\n\n\nThe fix is to give each `__init__` `**kwargs` and call `super().__init__(**kwargs)` to forward the leftovers, the pattern from the cooperative example earlier. Without that, the first class in the MRO consumes all the arguments and the rest never run.","pageType":"python"}

super() Function

Get Premium