{"title":"Inheritance Basics","description":"","content":"Inheritance lets one class build on another without copying its code. You define a general class once, then carve out specialized versions of it that reuse the general behavior and add or change pieces as needed. This lesson covers single inheritance: one subclass, one parent, the `super()` call, method overriding, and the two builtins (`isinstance` and `issubclass`) you use to ask about the relationship.\n\n---\n\n# The \"is-a\" Relationship\n\nInheritance models an \"is-a\" relationship. A `DigitalProduct` is a `Product`. A `PhysicalProduct` is also a `Product`. They share the things every product has (an ID, a name, a price), but each has its own twist: a digital product has a download link, a physical product has a weight for shipping.\n\nWhen you find yourself writing two classes that share most of their attributes and methods, that's the signal. Instead of repeating the shared parts, you put them in a parent class and let the specialized classes inherit them. Each subclass keeps everything from the parent and adds whatever makes it different.\n\nThe opposite of \"is-a\" is \"has-a\". A `Cart` has a list of `Product` objects, but a `Cart` is not a `Product`, so a `Cart` doesn't inherit from `Product`. Mixing these up is one of the most common design mistakes when learners first meet inheritance. If the relationship is \"has-a\", you store the other object as an attribute; only \"is-a\" earns inheritance.\n\n\n```mermaid\nflowchart TD\n Product[\"Product
(parent)\"]:::cyan\n Digital[\"DigitalProduct
(child)\"]:::orange\n Physical[\"PhysicalProduct
(child)\"]:::orange\n\n Product --> Digital\n Product --> Physical\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\nThe arrows point from parent to child, which is the standard reading direction in a class hierarchy. `DigitalProduct` and `PhysicalProduct` both inherit from `Product`. Everything `Product` defines is automatically available on both children, and each child is free to add its own attributes and methods on top.\n\n---\n\n# Defining a Subclass\n\nThe syntax is a single change to the `class` line. Where a normal class is `class Name:`, a subclass puts the parent's name in parentheses after its own:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name, price):\n self.product_id = product_id\n self.name = name\n self.price = price\n\n def describe(self):\n return f\"{self.name} (#{self.product_id}): ${self.price:.2f}\"\n\nclass DigitalProduct(Product):\n pass\n\nbook = DigitalProduct(101, \"Python Crash Course\", 29.99)\nprint(book.describe())\nprint(book.name)\n```\n\n\n`DigitalProduct` inherits from `Product` and defines nothing of its own. The `pass` is just a placeholder body. Even so, `DigitalProduct` instances have an `__init__`, a `describe` method, and a `name` attribute, all of them coming from the parent. That's the whole point of inheritance: you get the parent's behavior for free.\n\nWhen Python looks up an attribute on a `DigitalProduct` instance, it first checks the instance itself, then the `DigitalProduct` class, then `Product`, then the implicit `object` at the top. The first match wins. For `book.describe()`, the search misses on the instance and on `DigitalProduct`, then hits on `Product`, so that's the method that runs.\n\nA useful mental model: the subclass starts out as a perfect copy of the parent, and you're free to add to it or change parts of it. You don't have to redefine anything that's already correct.\n\n---\n\n# Adding New Attributes and Methods\n\nA subclass that does nothing is just a renamed parent. The real value shows up when the subclass adds something the parent doesn't have. The simplest way to add behavior is to define new methods directly on the subclass:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name, price):\n self.product_id = product_id\n self.name = name\n self.price = price\n\n def describe(self):\n return f\"{self.name} (#{self.product_id}): ${self.price:.2f}\"\n\nclass DigitalProduct(Product):\n def download_link(self):\n return f\"https://store.example.com/download/{self.product_id}\"\n\nebook = DigitalProduct(101, \"Python Crash Course\", 29.99)\nprint(ebook.describe())\nprint(ebook.download_link())\n```\n\n\n`DigitalProduct` keeps everything from `Product` and adds a `download_link` method. The new method uses `self.product_id`, which was set by the parent's `__init__`. The subclass can freely read any attribute the parent created; from the method's point of view, there's just one `self` object with all the attributes on it.\n\nMethods are easy. Adding new attributes is where most learners trip up, because attributes are typically created in `__init__`, and a subclass that needs its own attributes has to handle the initialization carefully. That's the next section.\n\n---\n\n# Overriding `__init__` and Using `super()`\n\nIf a subclass needs an extra attribute that the parent doesn't know about, you can't just sneak it in. You have to give the subclass its own `__init__` that accepts the new piece of data and stores it. The catch is that the parent's `__init__` still needs to run, otherwise the parent's attributes never get set.\n\nThe wrong way is to retype the parent's setup:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name, price):\n self.product_id = product_id\n self.name = name\n self.price = price\n\nclass DigitalProduct(Product):\n def __init__(self, product_id, name, price, download_url):\n # Retyping the parent's setup. Don't do this.\n self.product_id = product_id\n self.name = name\n self.price = price\n self.download_url = download_url\n```\n\n\nThis works, but it duplicates the parent's logic. If `Product.__init__` ever changes (a validation check, a default value, an extra computed attribute), the subclass silently drifts out of sync. The right approach is to ask the parent to do its own job, then add the new piece on top. That's what `super()` is for:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name, price):\n self.product_id = product_id\n self.name = name\n self.price = price\n\n def describe(self):\n return f\"{self.name} (#{self.product_id}): ${self.price:.2f}\"\n\nclass DigitalProduct(Product):\n def __init__(self, product_id, name, price, download_url):\n super().__init__(product_id, name, price)\n self.download_url = download_url\n\nebook = DigitalProduct(101, \"Python Crash Course\", 29.99, \"https://store.example.com/dl/101\")\nprint(ebook.describe())\nprint(ebook.download_url)\n```\n\n\n`super()` returns a proxy that lets you call methods on the parent class as if you were the parent. `super().__init__(product_id, name, price)` tells Python to run `Product.__init__` with the given arguments, which sets `self.product_id`, `self.name`, and `self.price` on the new instance. Then `self.download_url = download_url` adds the subclass's own piece.\n\nThe order matters. Call `super().__init__` first so the parent's attributes exist before the subclass touches anything. Adding subclass-specific attributes goes after the `super()` call.\n\n\n> **INFO**\n>\n> **Tip:** `super()` with no arguments works inside any method that lives in a class. Python figures out the parent and the current instance from context. The longer form `super(DigitalProduct, self)` is older syntax that does the same thing and is rarely needed in modern code.\n\n\nA second subclass with different extras works the same way:\n\n\n```python\nclass PhysicalProduct(Product):\n def __init__(self, product_id, name, price, weight_kg):\n super().__init__(product_id, name, price)\n self.weight_kg = weight_kg\n\n def shipping_cost(self):\n return 5.00 + self.weight_kg * 2.50\n\nmug = PhysicalProduct(202, \"Coffee Mug\", 12.99, 0.4)\nprint(mug.describe())\nprint(f\"Shipping: ${mug.shipping_cost():.2f}\")\n```\n\n\n`PhysicalProduct` calls the same parent `__init__` to set the shared three attributes, then adds `weight_kg`. The new `shipping_cost` method uses `weight_kg` to compute the cost. Both subclasses share `describe` because neither overrides it; both reach back to `Product` for the common setup; each adds the bit that's specific to its kind of product.\n\n---\n\n# Method Overriding\n\nInheriting a method is convenient when the parent's version is already right. When it isn't, the subclass can replace the method by defining one with the same name. This is **overriding**, and it's how subclasses customize behavior they inherited.\n\nSay `Product.describe` produces a fine generic description, but for digital products you'd rather show the download URL too. Define `describe` in `DigitalProduct`:\n\n\n```python\nclass Product:\n def __init__(self, product_id, name, price):\n self.product_id = product_id\n self.name = name\n self.price = price\n\n def describe(self):\n return f\"{self.name} (#{self.product_id}): ${self.price:.2f}\"\n\nclass DigitalProduct(Product):\n def __init__(self, product_id, name, price, download_url):\n super().__init__(product_id, name, price)\n self.download_url = download_url\n\n def describe(self):\n return f\"[Digital] {self.name} (#{self.product_id}): ${self.price:.2f} - {self.download_url}\"\n\ngeneric = Product(1, \"Notebook\", 4.99)\nebook = DigitalProduct(101, \"Python Crash Course\", 29.99, \"https://store.example.com/dl/101\")\n\nprint(generic.describe())\nprint(ebook.describe())\n```\n\n\nTwo calls, two different methods. `generic.describe()` finds `describe` on `Product` because there's nothing more specific. `ebook.describe()` finds the override on `DigitalProduct` first, so it never reaches the parent's version. The attribute-lookup rule from earlier is doing the work: Python checks the most specific class first and walks up the chain only if nothing matches.\n\nSometimes you don't want to replace the parent's method entirely; you want to extend it. The pattern is to call `super().method()` from inside the override and add to its result:\n\n\n```python\nclass PhysicalProduct(Product):\n def __init__(self, product_id, name, price, weight_kg):\n super().__init__(product_id, name, price)\n self.weight_kg = weight_kg\n\n def describe(self):\n base = super().describe()\n return f\"{base} [ships {self.weight_kg}kg]\"\n\nmug = PhysicalProduct(202, \"Coffee Mug\", 12.99, 0.4)\nprint(mug.describe())\n```\n\n\n`super().describe()` runs `Product.describe(self)` and returns its string. The subclass appends the shipping note and returns the combined result. This pattern, \"do the parent's thing, then add my thing\", is the natural use of `super()` outside `__init__`. It avoids duplicating the parent's logic and stays correct even if the parent's `describe` changes later.\n\n\n> **INFO**\n>\n> **Cost:** Method lookup walks the class chain on every call. For single inheritance with one or two parents, the cost is tiny, Python caches method lookups internally. It only becomes worth thinking about for deep hierarchies (six or seven levels), which are rare and usually a sign the design wants flattening.\n\n\n---\n\n# A Customer Hierarchy\n\nInheritance also shows up in places that aren't about products. Say the store has regular customers and premium customers. Both have a name and an email; premium customers also have a tier (silver, gold, platinum) and get a discount on every order.\n\n\n```python\nclass Customer:\n def __init__(self, customer_id, name, email):\n self.customer_id = customer_id\n self.name = name\n self.email = email\n\n def discount_percent(self):\n return 0\n\n def summary(self):\n return f\"Customer #{self.customer_id}: {self.name} <{self.email}>\"\n\nclass PremiumCustomer(Customer):\n TIER_DISCOUNTS = {\"silver\": 5, \"gold\": 10, \"platinum\": 15}\n\n def __init__(self, customer_id, name, email, tier):\n super().__init__(customer_id, name, email)\n self.tier = tier\n\n def discount_percent(self):\n return self.TIER_DISCOUNTS.get(self.tier, 0)\n\n def summary(self):\n base = super().summary()\n return f\"{base} [{self.tier.title()} member, {self.discount_percent()}% off]\"\n\nregular = Customer(1, \"Alice\", \"alice@example.com\")\npremium = PremiumCustomer(2, \"Bob\", \"bob@example.com\", \"gold\")\n\nprint(regular.summary())\nprint(f\" discount: {regular.discount_percent()}%\")\nprint(premium.summary())\nprint(f\" discount: {premium.discount_percent()}%\")\n```\n\n\nA few things are worth pointing out. The parent's `discount_percent` returns `0`, which is the right default for a regular customer. The subclass overrides it to look up the tier's discount instead. The parent's `summary` returns the basic line; the subclass extends it with the tier badge and percentage. `TIER_DISCOUNTS` is a class-level attribute on `PremiumCustomer` only, which means it lives on the subclass and the parent doesn't know about it. That's fine. Subclasses can hold class-level data the parent doesn't share.\n\n\n```mermaid\nflowchart TD\n Customer[\"Customer
customer_id, name, email
discount_percent() = 0
summary()\"]:::cyan\n Premium[\"PremiumCustomer
+ tier
+ TIER_DISCOUNTS
override discount_percent()
override summary()\"]:::orange\n\n Customer --> Premium\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n`PremiumCustomer` keeps everything `Customer` has and adds or overrides a few pieces. The diagram is a quick visual summary of what's shared (in the parent) versus what's new or changed (in the child).\n\n---\n\n# Checking Types: `isinstance` and `issubclass`\n\nWhen you have an inheritance chain, you sometimes need to ask \"is this object one of these types?\" or \"is this class a subclass of that one?\". Python has two builtins for that.\n\n`isinstance(obj, ClassName)` returns `True` if `obj` is an instance of `ClassName` **or any of its subclasses**. That second half is the important part. A `PremiumCustomer` instance is an instance of `Customer`, because every `PremiumCustomer` is a `Customer`.\n\n\n```python\nregular = Customer(1, \"Alice\", \"alice@example.com\")\npremium = PremiumCustomer(2, \"Bob\", \"bob@example.com\", \"gold\")\n\nprint(isinstance(regular, Customer))\nprint(isinstance(premium, Customer))\nprint(isinstance(premium, PremiumCustomer))\nprint(isinstance(regular, PremiumCustomer))\n```\n\n\n`regular` is a plain `Customer`, so the test against `Customer` is `True` and the test against `PremiumCustomer` is `False`. `premium` is both a `PremiumCustomer` and a `Customer`, because of inheritance. That's how Python answers \"is this object of this kind, or any more specific kind?\".\n\n`issubclass(ChildClass, ParentClass)` answers the same question at the class level. No instance involved, just the class objects:\n\n\n```python\nprint(issubclass(PremiumCustomer, Customer))\nprint(issubclass(Customer, PremiumCustomer))\nprint(issubclass(DigitalProduct, Product))\nprint(issubclass(PhysicalProduct, Product))\n```\n\n\n`PremiumCustomer` is a subclass of `Customer`, but not the other way around. The direction matters: `issubclass(A, B)` is true when `A` inherits from `B` (or `A` is `B`), not when `B` inherits from `A`.\n\nBoth functions also accept a tuple of classes for the second argument, which is handy when you want to check membership in any of several types:\n\n\n```python\nitems = [\n DigitalProduct(101, \"Python Crash Course\", 29.99, \"url\"),\n PhysicalProduct(202, \"Coffee Mug\", 12.99, 0.4),\n]\n\nfor item in items:\n if isinstance(item, (DigitalProduct, PhysicalProduct)):\n print(f\"{item.name} is a known product type\")\n```\n\n\nA note before moving on: it's easy to overuse `isinstance` to branch on the type of an object, like `if isinstance(p, DigitalProduct): ... elif isinstance(p, PhysicalProduct): ...`. That's a code smell. The cleaner approach is to put the differing behavior in methods on each subclass and just call the method, which works the same way regardless of the specific type. That technique is called polymorphism and it's the topic of a later chapter. For now, `isinstance` is mainly useful for sanity checks and for guards at the edges of your code where data of unknown type arrives.\n\n---\n\n# Every Class Inherits From `object`\n\nEven when you write `class Product:` with no parent in parentheses, Python silently sets the parent to a builtin class called `object`. It sits at the top of every class hierarchy in Python.\n\n\n```python\nclass Product:\n pass\n\nprint(Product.__bases__)\nprint(issubclass(Product, object))\nprint(isinstance(Product(), object))\n```\n\n\n`__bases__` is the tuple of immediate parent classes. For a class with no explicit parent, it's `(object,)`. Every class is a subclass of `object`, and every instance is an instance of `object`. There are no exceptions, this is true for builtins like `list` and `int` as well.\n\n`object` is what gives every Python class its baseline behavior: the methods that make objects work with `print`, with `==`, with `hash`, with `repr`. Useful methods you've already met (`__init__`, `__str__`, `__repr__`, `__eq__`) all have default versions on `object` that your classes inherit. When you write `__init__` in your own class, you're really overriding `object.__init__`, and `super().__init__()` in the most general case is reaching all the way up to `object` to do nothing in particular.\n\nThis matters for two reasons. First, you never have to explicitly inherit from `object`; Python 3 does it automatically. (In old Python 2 code, you might see `class Product(object):`, which was required for some features back then. In Python 3 it's redundant and you can drop it.) Second, when your class inherits from another class, the chain doesn't stop at the immediate parent: it continues up to `object`. So `PremiumCustomer` inherits from `Customer`, and `Customer` inherits from `object`, which means `PremiumCustomer` indirectly inherits from `object` too.\n\n\n```python\nprint(isinstance(PremiumCustomer(1, \"Bob\", \"bob@example.com\", \"gold\"), object))\nprint(issubclass(PremiumCustomer, object))\n```\n\n\nThe takeaway is simple: there's always a parent. If your class doesn't name one, the parent is `object`. The full chain from your subclass up through `object` is what Python walks when looking up an attribute or a method.","pageType":"python"}

Inheritance Basics

Get Premium