🏫 Inheritance Deep Dive · School System

School System
The Inheritance Playground

A comprehensive exploration of Python inheritance through a school system. Beyond the basic Person hierarchy, this guide covers Method Resolution Order, super() mechanics, composition vs inheritance, the Liskov Substitution Principle, and real-world design decisions — all with live, runnable code.

Back to Inheritance Guide Jump to Playground
01 — Beyond the Basics

Why Inheritance Matters in Real-World Python

Inheritance is one of the most powerful — and most misunderstood — tools in object-oriented programming. At its core, inheritance is about code reuse and type relationships. But in practice, it's also about architectural clarity, maintainability, and extensibility. When used correctly, inheritance turns a chaotic collection of functions into a coherent, self-documenting system that can evolve over years without breaking.

🧬 The School System as a Teaching Vehicle

The school system hierarchy — Person as a base, with Student, Teacher, and Staff as subclasses — is a rich teaching example for inheritance. It's familiar enough to grasp immediately, yet it contains all the key elements of inheritance: a shared interface, specialized implementations, and a clear "is-a" relationship. The school domain also naturally exposes important design decisions like when to use composition vs inheritance.

In the real world, similar hierarchies appear everywhere: in HR systems (employee management), healthcare systems (patient records), e-commerce platforms (user roles), and content management systems (user permissions). Understanding how to design and extend these hierarchies is a fundamental skill for any serious Python developer.

📐 What Makes This Guide Different

Most tutorials stop after showing you how to write class Student(Person): and override display_info(). This guide goes much further. You'll learn:

  • How Python's Method Resolution Order (MRO) actually works — and why it matters
  • The difference between super() in single vs multiple inheritance
  • When to use inheritance vs composition — with concrete trade-offs
  • The Liskov Substitution Principle and why Student inheriting from Person is natural
  • How to design hierarchies that don't break when requirements change
  • Abstract base classes and mixins — advanced inheritance patterns used in production

🎯 Who This Is For: This guide is for developers who already understand the basics of Python classes and want to truly master inheritance. If you've ever wondered why your super() call didn't work as expected, or when to use inheritance vs composition, this is for you.

📊 The School Family Tree

Python Inheritance Hierarchy — School System
Person ↙ Student ↘ Teacher ↘ Staff
Student → student_id, courses, enroll()  |  Teacher → subject, schedule, assign_grade()  |  Staff → department, hours, clock_in()

Note: Person is the abstract base class. Student, Teacher, and Staff are concrete subclasses with specialized behavior.

02 — The Mechanics of Inheritance

Understanding How Python Really Does Inheritance

Before we dive into code, let's build a solid mental model of how inheritance works in Python. This section covers the critical concepts that separate a beginner from an expert — Method Resolution Order, the power of super(), and the trade-offs between inheritance and composition.

🔍 The Method Resolution Order (MRO)

When you call a method on an instance, Python needs to decide which method to execute. In single inheritance, this is straightforward: search the child class, then the parent, then the grandparent, and so on. But with multiple inheritance, the order is more complex.

Python uses the C3 linearization algorithm to compute a consistent, monotonic MRO. You can see it with ClassName.__mro__. The MRO guarantees that a class always appears before its parents, and that the order is predictable across all classes in the hierarchy.

Key Insight: The MRO is not just a list of classes — it's the search path. When you call super().method(), you're calling the next method in the MRO, not necessarily the parent class's method. This is why super() works so elegantly in multiple inheritance — it's MRO-aware.

class A: pass
class B(A): pass
class C(A): pass
class D(B, C): pass

print(D.__mro__)
# (<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <class 'object'>)
📝 What's happening here?
  1. MRO Order: D → B → C → A → object. Python searches D first, then B, then C, then A, then the base object class.
  2. Why B before C? Because D declares (B, C) — the left-to-right order determines priority.
  3. Why A last? Even though both B and C inherit from A, C3 ensures A is visited only once, after both B and C have been checked.
  4. Why this matters: If B and C both define a method, the version from B will be used. If only C defines it, C's version will be used. If neither defines it, A's version is used.

Real-world application: Django uses MRO extensively in its class-based views. When you inherit from ListView and LoginRequiredMixin, the MRO determines which method runs first — which is why mixins usually appear before the base class in the inheritance list.

🔧 super() — More Than Just a Parent Call

In most languages, super is a hard-coded reference to the immediate parent class. In Python, super() is far more dynamic. It returns a proxy object that delegates method calls to the next class in the MRO — which might not be the parent at all.

This is what makes super() so powerful in cooperative multiple inheritance. It ensures that in a diamond hierarchy (A → B, A → C, D → B, C), every class's method gets called exactly once, in the correct order, even if not every class explicitly calls super(). 

class Person:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email

class Student(Person):
    def __init__(self, name: str, email: str, student_id: str):
        super().__init__(name, email)
        self.student_id = student_id

# MRO: Student → Person → object

⚠️ Common Mistake: Calling super().__init__() with the wrong number of arguments is a common error. Ensure that the parent's __init__ signature matches your call, or use *args, **kwargs for flexible forwarding.

Best practice: In modern Python, use super() without arguments (Python 3+). It automatically resolves to the right class. This makes your code more maintainable and avoids hard-coding parent class names.

⚖️ Inheritance vs Composition — The Eternal Debate

"Favor composition over inheritance" is one of the most cited principles in OOP design. But what does it actually mean? And when should you still use inheritance?

Inheritance is an "is-a" relationship: a Student is a Person. Composition is a "has-a" relationship: a School has Teachers and Students. Inheritance is for specializing behavior; composition is for assembling capabilities.

AspectInheritanceComposition
Relationship"is-a""has-a"
Code reuseAutomatic via parentExplicit delegation
FlexibilityTight coupling to parentLoose coupling
Change impactParent changes affect all childrenChanges isolated to component
TestingNeed to test parent behaviorMock dependencies easily
ComplexityDeep hierarchies are hard to reason aboutFlat and modular

✅ Use Inheritance When

  • • There's a clear "is-a" relationship
  • • You need to override behavior
  • • You want polymorphism across a family of types
  • • The hierarchy is stable and unlikely to change

✅ Use Composition When

  • • There's a "has-a" relationship
  • • You want to reuse behavior without creating a type relationship
  • • The hierarchy is likely to change frequently
  • • You need to combine behaviors from many sources 
# Inheritance: Person → Student (is-a)
class Student(Person): pass

# Composition: School has a list of Students (has-a)
class School:
    def __init__(self):
        self.students = []
        self.teachers = []
    def add_student(self, student: Student):
        self.students.append(student)

💡 Pro Tip: In practice, many systems use both. Django models use inheritance for base model classes, but use composition for fields and managers. A well-designed system uses the right tool for the right job.

📐 The Liskov Substitution Principle (LSP)

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In other words, a subclass should be able to stand in for its parent class without breaking anything.

✅ Good Example: Student inheriting from Person.

A Person has a name and email. A Student is a person with a student ID and courses. A Student can be used anywhere a Person is expected — the behavior is consistent and doesn't break the parent's contract. This is a natural and correct use of inheritance.

⚠️ Potential Violation: If Student overrides a method in a way that changes its behavior in a way the parent didn't anticipate (e.g., changing how email validation works), it could violate LSP. Always ensure that overrides preserve the parent's behavioral contract.

class Person:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email
    def display_info(self) -> str:
        return f"{self.name} <{self.email}"

class Student(Person):
    def __init__(self, name: str, email: str, student_id: str):
        super().__init__(name, email)
        self.student_id = student_id
    def display_info(self) -> str:
        # Extends the parent's behavior without breaking it
        return f"{super().display_info()} (ID: {self.student_id})"

💡 The Lesson: LSP is about behavioral compatibility, not just structural compatibility. A subclass can add new behavior, but it shouldn't change the parent's behavior in ways that break code expecting the parent's contract.

🏗️ Abstract Base Classes & Mixins — Advanced Patterns

Python's abc module lets you define abstract base classes that enforce a contract on subclasses. This is useful when you want to ensure that every subclass implements certain methods. Mixins are small classes that provide reusable behavior to be mixed into other classes via multiple inheritance. 

from abc import ABC, abstractmethod

class Person(ABC):
    @abstractmethod
    def get_role(self) -> str: pass

    def display_info(self) -> str:
        return f"{self.get_role()}: {self.name}"

class JsonMixin:
    def to_json(self) -> str:
        import json
        return json.dumps(self.__dict__, default=str)

class Student(Person, JsonMixin):
    def __init__(self, name, email, student_id):
        self.name = name
        self.email = email
        self.student_id = student_id
    def get_role(self) -> str:
        return "Student"

s = Student("Alice", "alice@school.edu", "S123")
print(s.display_info())
print(s.to_json())

✅ Best Practice: Use ABC and @abstractmethod whenever you want to define an interface that multiple classes will implement. Use mixins for reusable behavior that doesn't depend on a specific hierarchy. Keep mixins small and focused on a single responsibility.

03 — The Code

School System — Full Implementation

This is the complete school system hierarchy with type hints, docstrings, and an abstract base class. Notice how display_info() is defined once in Person and works for every subclass — that's polymorphism in action. The __str__ and __repr__ methods make instances printable and debuggable.

python · school_system.py 
from abc import ABC, abstractmethod
from typing import List, Optional
from datetime import datetime

class Person(ABC):
    """Abstract base class for all people in the school system."""

    def __init__(self, name: str, email: str, phone: Optional[str] = None):
        self.name = name
        self.email = email
        self.phone = phone
        self._created_at = datetime.now()

    @abstractmethod
    def get_role(self) -> str:
        """Return the role of this person (Student, Teacher, Staff)."""
        pass

    def display_info(self) -> str:
        """Display basic information about this person."""
        info = f"{self.get_role()}: {self.name} <{self.email}"
        if self.phone:
            info += f" | {self.phone}"
        return info

    def __str__(self) -> str:
        return self.display_info()

    def __repr__(self) -> str:
        return f"{type(self).__name__}({self._repr_params()})"

    def _repr_params(self) -> str:
        return f"name={self.name}, email={self.email}"

class Student(Person):
    """A student with a student ID and enrolled courses."""

    def __init__(self, name: str, email: str, student_id: str,
                 phone: Optional[str] = None, grade_level: int = 9):
        super().__init__(name, email, phone)
        self.student_id = student_id
        self.grade_level = grade_level
        self.courses: List[str] = []
        self.gpa: float = 0.0

    def get_role(self) -> str:
        return "Student"

    def enroll(self, course: str) -> None:
        """Enroll the student in a course."""
        if course not in self.courses:
            self.courses.append(course)

    def display_info(self) -> str:
        """Display student-specific information."""
        base = super().display_info()
        courses = ", ".join(self.courses) if self.courses else "None"
        return f"{base} | ID: {self.student_id} | Grade: {self.grade_level} | GPA: {self.gpa:.2f} | Courses: {courses}"

    def _repr_params(self) -> str:
        return f"name={self.name}, student_id={self.student_id}"

class Teacher(Person):
    """A teacher with a subject and schedule."""

    def __init__(self, name: str, email: str, subject: str,
                 phone: Optional[str] = None, employee_id: str = ""):
        super().__init__(name, email, phone)
        self.subject = subject
        self.employee_id = employee_id
        self.schedule: List[str] = []
        self.students: List[Student] = []

    def get_role(self) -> str:
        return "Teacher"

    def assign_grade(self, student: Student, grade: float) -> None:
        """Assign a grade to a student (updates GPA)."""
        student.gpa = (student.gpa + grade) / 2

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Subject: {self.subject} | ID: {self.employee_id} | Students: {len(self.students)}"

    def _repr_params(self) -> str:
        return f"name={self.name}, subject={self.subject}"

class Staff(Person):
    """Staff member with department and work hours."""

    def __init__(self, name: str, email: str, department: str,
                 phone: Optional[str] = None, role: str = "Staff"):
        super().__init__(name, email, phone)
        self.department = department
        self.role = role
        self.hours = 40

    def get_role(self) -> str:
        return "Staff"

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Dept: {self.department} | Role: {self.role} | Hours: {self.hours}"

    def _repr_params(self) -> str:
        return f"name={self.name}, department={self.department}"

# Demo
people = [
    Student("Alice", "alice@school.edu", "S123", grade_level=10),
    Student("Bob", "bob@school.edu", "S124", phone="555-0101", grade_level=11),
    Teacher("Ms. Smith", "smith@school.edu", "Mathematics", employee_id="T001"),
    Staff("Mr. Johnson", "johnson@school.edu", "Administration", role="Principal")
]

for p in people:
    print(p.display_info())

# Demonstrate enrollment and grading
alice = people[0]
ms_smith = people[2]
alice.enroll("Mathematics")
alice.enroll("Physics")
ms_smith.assign_grade(alice, 92.5)
print(f"\nAfter enrollment and grading:")
print(alice.display_info())

print(f"\nMRO of Student: {Student.__mro__}")
📝 Why This Code Demonstrates Inheritance
  1. Abstract base class Person — defines the common interface with @abstractmethod for get_role(). This enforces that all subclasses identify their role.
  2. display_info() is inherited and extended — each subclass calls super().display_info() to get the base behavior, then adds its own details.
  3. Specialized behavior — Student adds enrollment and GPA tracking, Teacher adds grading, and Staff adds department and hours.
  4. Polymorphism in action — the for loop treats every person identically, yet each produces the correct role-specific output.
  5. __str__ and __repr__ — these dunder methods make instances printable and debuggable, a best practice for any class hierarchy.
04 — Live Playground

Interactive School System

Modify the code below — add new people, change attributes, or experiment with inheritance. Click Run to see the output. This is your sandbox for exploring inheritance. Try adding a new role like Volunteer or Counselor.

python · school_playground.py 
from abc import ABC, abstractmethod
from typing import List, Optional

class Person(ABC):
    def __init__(self, name: str, email: str, phone: Optional[str] = None):
        self.name = name
        self.email = email
        self.phone = phone

    @abstractmethod
    def get_role(self) -> str: pass

    def display_info(self) -> str:
        info = f"{self.get_role()}: {self.name} <{self.email}"
        if self.phone:
            info += f" | {self.phone}"
        return info

    def __str__(self) -> str:
        return self.display_info()

class Student(Person):
    def __init__(self, name: str, email: str, student_id: str,
                 phone: Optional[str] = None, grade_level: int = 9):
        super().__init__(name, email, phone)
        self.student_id = student_id
        self.grade_level = grade_level
        self.courses: List[str] = []
        self.gpa: float = 0.0

    def get_role(self) -> str:
        return "Student"

    def enroll(self, course: str) -> None:
        if course not in self.courses:
            self.courses.append(course)

    def display_info(self) -> str:
        base = super().display_info()
        courses = ", ".join(self.courses) if self.courses else "None"
        return f"{base} | ID: {self.student_id} | Grade: {self.grade_level} | GPA: {self.gpa:.2f} | Courses: {courses}"

class Teacher(Person):
    def __init__(self, name: str, email: str, subject: str,
                 phone: Optional[str] = None, employee_id: str = ""):
        super().__init__(name, email, phone)
        self.subject = subject
        self.employee_id = employee_id

    def get_role(self) -> str:
        return "Teacher"

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Subject: {self.subject} | ID: {self.employee_id}"

class Staff(Person):
    def __init__(self, name: str, email: str, department: str,
                 phone: Optional[str] = None, role: str = "Staff"):
        super().__init__(name, email, phone)
        self.department = department
        self.role = role

    def get_role(self) -> str:
        return "Staff"

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Dept: {self.department} | Role: {self.role}"

# --- Playground: Edit these values ---
people = [
    Student("Alice", "alice@school.edu", "S123", grade_level=10),
    Student("Bob", "bob@school.edu", "S124", phone="555-0101", grade_level=11),
    Teacher("Ms. Smith", "smith@school.edu", "Mathematics", employee_id="T001"),
    Staff("Mr. Johnson", "johnson@school.edu", "Administration", role="Principal")
]

for p in people:
    print(p.display_info())

# Challenge: Uncomment and implement a Volunteer or Counselor class
# class Volunteer(Person):
#     def __init__(self, name, email, hours_per_week):
#         super().__init__(name, email)
#         self.hours_per_week = hours_per_week
#     def get_role(self):
#         return "Volunteer"
#     def display_info(self):
#         base = super().display_info()
#         return f"{base} | Hours: {self.hours_per_week}/week"
# people.append(Volunteer("Charlie", "charlie@school.edu", 10))

✏️ Try it yourself: Add a new role like Volunteer or Counselor. Experiment with adding new attributes or methods. Hit Run to see your changes live. Try breaking the LSP by overriding display_info() in a way that doesn't call super() — what happens to the output?

05 — Practice Exercises

Reinforce Your Understanding

Work through these exercises to solidify your grasp of inheritance. Each exercise builds on the school system hierarchy and introduces a new concept.

📝 Exercise 1: Add a New Role — Volunteer

Create a Volunteer class that inherits from Person. It should have: hours_per_week (int) and a method log_hours() that adds to a total. Override display_info() to include the hours.

Hint: Remember to call super().__init__() and extend the parent's display_info() rather than replacing it. 
class Volunteer(Person):
    def __init__(self, name: str, email: str, hours_per_week: int,
                 phone: Optional[str] = None):
        super().__init__(name, email, phone)
        self.hours_per_week = hours_per_week
        self.total_hours = 0

    def get_role(self) -> str:
        return "Volunteer"

    def log_hours(self, hours: int) -> None:
        self.total_hours += hours

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Hours/week: {self.hours_per_week} | Total: {self.total_hours}"

📝 Exercise 2: Override display_info() for Teacher

Override the display_info() method in Teacher to also display the number of students in their class. Add a method add_student() that adds a student to the teacher's roster.

Hint: Use super().display_info() to get the base behavior, then append the additional information. 
class Teacher(Person):
    def __init__(self, name, email, subject, phone=None, employee_id=""):
        super().__init__(name, email, phone)
        self.subject = subject
        self.employee_id = employee_id
        self.students = []  # List of Student objects

    def get_role(self) -> str:
        return "Teacher"

    def add_student(self, student: Student) -> None:
        if student not in self.students:
            self.students.append(student)

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | Subject: {self.subject} | ID: {self.employee_id} | Students: {len(self.students)}"

📝 Exercise 3: Liskov Substitution — Create a Generic School

Create a School class that uses composition to manage lists of Person objects. Implement methods to add people, list all students, and calculate the average GPA across all students. This demonstrates composition as an alternative to inheritance.

Hint: The School class should have lists for students, teachers, and staff. Use isinstance() to filter by type when needed. 
class School:
    def __init__(self, name: str):
        self.name = name
        self._people: List[Person] = []

    def add_person(self, person: Person) -> None:
        self._people.append(person)

    def get_students(self) -> List[Student]:
        return [p for p in self._people if isinstance(p, Student)]

    def get_teachers(self) -> List[Teacher]:
        return [p for p in self._people if isinstance(p, Teacher)]

    def average_gpa(self) -> float:
        students = self.get_students()
        if not students:
            return 0.0
        total = sum(s.gpa for s in students)
        return total / len(students)

school = School("Python High")
school.add_person(Student("Alice", "alice@school.edu", "S123", grade_level=10))
school.add_person(Teacher("Ms. Smith", "smith@school.edu", "Mathematics"))
print(f"School: {school.name} | Students: {len(school.get_students())}")

🔥 Challenge: Refactor Using Mixins

Create a GradableMixin that adds GPA tracking to any class that uses it. Then use it with Student and create a Course class that also uses the mixin to track course grades. This demonstrates the power of mixins for reusable behavior.

Hint: The mixin should have a gpa attribute and methods to update it. Use multiple inheritance to add the mixin to existing classes. 
class GradableMixin:
    def __init__(self, *args, **kwargs):
        self.grades: List[float] = []
        super().__init__(*args, **kwargs)

    def add_grade(self, grade: float) -> None:
        self.grades.append(grade)

    def gpa(self) -> float:
        if not self.grades:
            return 0.0
        return sum(self.grades) / len(self.grades)

class Student(Person, GradableMixin):
    def __init__(self, name, email, student_id, phone=None, grade_level=9):
        super().__init__(name, email, phone, grade_level=grade_level)
        self.student_id = student_id
        self.grade_level = grade_level
        self.courses = []

    def display_info(self) -> str:
        base = super().display_info()
        return f"{base} | ID: {self.student_id} | GPA: {self.gpa():.2f}"
06 — Frequently Asked Questions

Common Questions About Inheritance

Why use inheritance instead of just copying code?

+

Inheritance centralizes shared logic in one place. If you copy-paste, a bug fix or change must be repeated in every copy. With inheritance, you update the parent once and all children benefit automatically. It also establishes a clear "is-a" relationship that makes your code more intuitive and self-documenting. In large codebases, this can save hundreds of hours of maintenance time.

What's the difference between inheritance and composition?

+

Inheritance is an "is-a" relationship: a Student is a Person. Composition is a "has-a" relationship: a School has Students. Inheritance is for specializing behavior; composition is for assembling capabilities. Use inheritance when you genuinely have a subtype; use composition when you just need to reuse functionality without creating a type hierarchy. In practice, composition often leads to more flexible and maintainable code.

What is the super() function, and why use it?

+

super() returns a proxy object that delegates method calls to the next class in the Method Resolution Order. It's essential in __init__ to ensure the parent's initialization runs. It also makes overrides extend rather than replace — you can call super().method() to run the parent's logic and then add your own. In multiple inheritance, super() ensures cooperative method calls across all classes in the hierarchy, which is why it's preferred over hard-coding parent class names.

Can a class inherit from multiple parent classes?

+

Yes — Python supports multiple inheritance: class C(A, B):. The Method Resolution Order determines which parent is searched first. Use it sparingly; it can make code harder to reason about. Mixins (small, focused classes that provide reusable behavior) are a common and safe use of multiple inheritance. For example, Django uses mixins extensively for permission checking, pagination, and form handling.

What is the Method Resolution Order (MRO)?

+

MRO is the order in which Python searches for a method or attribute in a class hierarchy. You can view it with ClassName.__mro__. Python uses the C3 linearization algorithm to compute a consistent, predictable order even with complex multiple inheritance. The MRO guarantees that a class appears before its parents, and that the order is monotonic — it never changes based on where you start the search. Understanding MRO is crucial for debugging method resolution in complex hierarchies.

When should I use abstract base classes (ABCs)?

+

Use ABCs when you want to define a contract that all subclasses must fulfill. An ABC with abstract methods cannot be instantiated directly, and any subclass that doesn't implement all abstract methods will raise an error at instantiation time. ABCs are great for frameworks and libraries where you want to enforce a consistent interface across many implementations. They're also useful for documenting the expected behavior of a class hierarchy. In Python 3.8+, you can also use Protocol for structural subtyping.

07 — Continue Learning

Explore the Full OOP Series

Inheritance is the second of four interconnected pillars. Each one builds on the last. Explore the complete journey.

🔒
Encapsulation

Bundle data with methods. Control access. Protect state. The guardian of object integrity.

Explore
🎭
Abstraction

Hide implementation complexity. Expose only what is necessary. Think in concepts, not mechanics.

Explore Current
🧬
Inheritance

Build on existing classes. Reuse code elegantly. Create natural type hierarchies.

You are here
🌀
Polymorphism

One interface, many forms. Duck typing. Write code that adapts to any conforming object.

Explore
08 — Stay in the Loop

Subscribe to Poetic Bytes

Level up your Python knowledge.

In-depth Python tutorials, AI insights, and software engineering guides — delivered straight to your inbox. No spam, ever.

Weekly Python tutorials AI & ML deep-dives OOP series updates Free, cancel anytime

🔒 Join 8,400+ developers. Your email is never shared or sold.

09 — Connect With Us

Follow Poetic Bytes

Stay connected across every platform. Get daily Python tips, OOP insights, and the latest AI developments — wherever you spend your time online.