Classes: Inheritance

29. Classes: Inheritance#

With inheritance, we can create a new class by extending an existing class. The new class inherits the existing class’s attributes and methods (the members). We can then add attributes and/or methods. We can also modify existing attributes and methods to change functionality.

As we look around the world, we can find many instances of hierarchy in which specialized classes exist. For example, the animal taxonomy serves to classify animals into different classes (taxonomic ranks based upon the different attributes that animals possess. Planes, cars, and trains are specialized cases of vehicles. Circles, triangles, and rectangles are specialized cases of shapes. You can also view these examples using the phrase “is-a”. A train is a vehicle. A circle is a shape. A dog is a mammal.

In object-oriented programming, inheritance creates this “is-a” relationship among classes. We build a new class from an existing class. The existing (original) class is called a parent, superclass, or base class. The superclass is the more general class. The new class is called a child, subclass, or derived class. This new class is the more specialized class. The subclass becomes specialized by adding attributes and/or methods. The subclass can also become more specialized by modifying the existing state or behavior.

In the previous notebook, we defined a BankAccount. However, many different types of bank accounts exist: checking, savings, money market, brokerage, etc. We also have transactions that can belong to those accounts. Again, though, we have different transactions types: deposit, withdrawal, transfer, purchase, etc. Then under deposit transactions, we have additional specialties: check, cash, ACH, etc. Similar specialties will also exist for the other transaction types.

As another example, consider different types of employees within a corporation. Corporations can have hourly employees, paid a fixed amount per hour and a specific multiplier for specialty shifts (holiday, weekend, nights). Corporations also can have salaried employees who earn a particular amount per pay period and commission employees who make a base salary per pay period plus a percentage of the gross sales they generate.

The below diagram is a Unified Modeling Language(UML) class diagram. These diagrams document classes, their relationships to each other, and each class’s members (attribute and methods). Each box represents a class. The top line contains that class name. The second area in the box contains the attributes, and the third area contains the methods.

Objects of the Employee class have three attributes - an ID, a name, and a job title - and no methods are defined. The HourlyEmployee class extends the Employee class by adding attributes for the employee’s hourly rate and the hours that the employee worked during the current pay period. The HourlyEmployee also adds behavior - a method to compute their pay. The SalariedEmployee class extends the Employee class by adding an attribute for the employee’s periodic salary amount. For example, if an employee earns $\$$120,000 annually and is paid twice a month, the periodic pay would be $\$$5,000. The SalariedEmployee class also defines a method to compute pay, but this differs from the HourlyEmployee’s behavior. CommissionedEmployee inherits the behavior and attributes of SalariedEmployee but adds an attribute to track their sales over the past pay period. Their pay calculation will “override” the SalariedEmployee class’s pay calculation as they receive a salary plus a percentage of their gross sales.

The following code cell defines the Employee class, the superclass for the three other classes. This code should be familiar based on the previous notebook. This code does create a calculate_pay() method, but any call to that will raise an exception. By defining a method here, we establish that any subclass must implement a calculate_pay() method. Similarly, the employee_type property produces “unknown” as we should not have any objects created as Employee.

class Employee:
    """Employee"""
    __id = 100  # must change name otherwise a recursive overflow error occurs
    
    def __init__(self, name, job_title):
        self.__id = Employee.__id
        Employee.__id += 1
        self.__name = name
        self.__job_title = job_title
        
    def __str__(self):
        return "ID #{:d}: {:s}({:s}, {:s})".format(self.id,self.name, self.job_title, self.employee_type)
    
    def __repr__(self):
        return str({ "id": self.id, "name": self.name, "job_title":self.job_title })
    
    @property
    def id(self):
        return self.__id

    @property
    def name(self):
        return self.__name
    
    @property
    def job_title(self):
        return self.__job_title
    
    
    @job_title.setter
    def job_title(self, new_title):
        self.__job_title = new_title
    
    @property
    def employee_type(self):
        return "unknown"
        
    
    def calculate_pay(self):
        raise  NotImplementedError("Employee subclasses must implement calculate_pay()")

Some sample code to perform ad-hoc testing that the class works.

a = Employee("Steve","Programmer")
b = Employee("Christine","Project Manager")
print(a)
repr(b)

ID #100: Steve(Programmer, unknown)

"{'id': 101, 'name': 'Christine', 'job_title': 'Project Manager'}"

Now, define a more robust set of unit tests for Employee.

import unittest

class TestEmployee(unittest.TestCase):
    def setUp(self):
        Employee._Employee__id = 100
        
    def test_create(self):
        import ast
        
        a = Employee("Steve","Programmer")
        b = Employee("Christine","Project Manager")
        self.assertNotEqual(a.id,b.id,"IDs are not unique")
        self.assertEqual(a.name,"Steve")
        self.assertEqual(b.name,"Christine")
        self.assertEqual(a.job_title,"Programmer")
        self.assertEqual(b.job_title,"Project Manager")
        self.assertEqual(str(a),"ID #100: Steve(Programmer, unknown)")
        self.assertEqual(ast.literal_eval(repr(b)),{'id': 101, 'name': 'Christine', 'job_title': 'Project Manager'})
        
    def test_calculate_pay_not_implemented(self):
        a = Employee("Steve","Programmer")
        with self.assertRaises(Exception) as context:
            a.calculate_pay()
        
        self.assertTrue(type(context.exception) == NotImplementedError)
        self.assertTrue("must implement" in context.exception.args[0])
        
    def test_change_job_title(self):
        a = Employee("Steve","Programmer")
        a.job_title = 'Senior Programmer'
        self.assertEqual(a.job_title,'Senior Programmer')
        self.assertEqual(str(a),"ID #100: Steve(Senior Programmer, unknown)")
        
unittest.main(argv=['unittest','TestEmployee'], verbosity=2, exit=False)

test_calculate_pay_not_implemented (__main__.TestEmployee.test_calculate_pay_not_implemented) ... 

ok

test_change_job_title (__main__.TestEmployee.test_change_job_title) ...

ok

test_create (__main__.TestEmployee.test_create) ...

ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK

<unittest.main.TestProgram at 0x106f167b0>

At this point, we have implemented our base Employee class and have a robust set of test cases for it.

Next, let’s look at defining the HourlyEmployee class. The following code block adds a few new details:

We define HourlyEmployee as a subclass of Employee. Subclasses are defined similarly to other classes, except we add the parent class name inside of parenthesis at the end. Syntax -
```
class ClassName(ParentClassName):
```
In the initializer, we make a call to the parent class with super(). As we have defined __init__ in the child class, the interpreter does not automatically call the corresponding method in the parent class. Therefore, we explicitly call the initializer with reference to the superclass (super()). This call ensures our code performs the steps to initialize the base Employee type properly. The __init__ method then continues with setting the attributes specific to instances of HourlyEmployee.
Note that in the initializer, we explicitly set __hours_worked to None. This statement defines that attribute. In calculate_pay(), we add a sanity check to our code to ensure hours_worked has a valid value with the assert statement. Programmers can place a conditional expression within an assert statement. If the expression evaluates to True, processing continues normally. If the expression evaluates to False, the interpreter raises an exception.
The HourlyEmployee class adds additional methods to support the hourly_rate and hours_worked attributes.
In addition to the __init__ method, the HourlyEmployee class also overrides the methods for employee_type and calculate_pay. By overriding methods, objects of type HourlyEmployee will use the behavior for the methods defined within HourlyEmployee itself. Any behavior defined in the parent class will not be performed unless explicitly called through the super() reference.
Notice that the HourlyEmployee class did not change the __str__ or __repr__ methods. In the test code in the following block, notice that when the __str__ method gets the employee type, it calls the method based on the actual class. i.e., an instance of Employee returns “unknown” while an instance of HourlyEmployee returns “hourly”.

from decimal import Decimal

class HourlyEmployee(Employee):
    """Hourly Employee"""
    
    
    def __init__(self, name, job_title,hourly_rate):
        super().__init__(name,job_title)
        self.__hourly_rate = Decimal(hourly_rate)
        self.__hours_worked = None        
        
    @property
    def employee_type(self):
        return "hourly"
        
    @property
    def hourly_rate(self):
        return self.__hourly_rate
    
    
    @hourly_rate.setter
    def hourly_rate(self, new_rate):
        self.__hourly_rate= new_rate        
        

    @property
    def hours_worked(self):
        return self.__hours_worked
    
    
    @hours_worked.setter
    def hours_worked(self, new_hours):
        self.__hours_worked = Decimal(new_hours)               
        
    def calculate_pay(self):
        assert type(self.hours_worked) is Decimal, "Hours worked not established"
        hours = self.hours_worked
        overtime_hours = Decimal(0)
        if hours > 40:
            overtime_hours = hours - Decimal(40.0)
            hours = Decimal(40.0)
        return hours * self.hourly_rate + overtime_hours * self.hourly_rate* Decimal(1.5)

Run some code to see how the HourlyEmployee class works.

c = HourlyEmployee("Max","System Administrator","54.76")
print(c)
print(c.name)
print(c.hours_worked)
print(c.calculate_pay())   # will cause an assertion error as hours_worked not set.

ID #102: Max(System Administrator, hourly)
Max
None

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
Cell In[5], line 5
      3 print(c.name)
      4 print(c.hours_worked)
----> 5 print(c.calculate_pay())   # will cause an assertion error as hours_worked not set.

Cell In[4], line 36, in HourlyEmployee.calculate_pay(self)
     35 def calculate_pay(self):
---> 36     assert type(self.hours_worked) is Decimal, "Hours worked not established"
     37     hours = self.hours_worked
     38     overtime_hours = Decimal(0)

AssertionError: Hours worked not established

Now define some additional test cases. First, we check that the parent functionality still works. We also check that the calculate_pay() method checks that hours_worked has a valid numerical value. We also check several equivalence classes for hours_worked in compute_pay() to cover amounts < 40 hours, amounts equal to 40 hours, and amounts greater than 60 hours. Finally, we check that the employee type value is correct for the different types.

import unittest

class TestHourlyEmployee(unittest.TestCase):
    def setUp(self):
        Employee._Employee__id = 100
        
    def test_create(self):
        a = HourlyEmployee("Max","System Administrator",65.0)
        self.assertEqual(a.name,"Max")
        self.assertEqual(a.job_title,"System Administrator")
        self.assertEqual(str(a),"ID #100: Max(System Administrator, hourly)")

    def test_compute_pay_no_hours(self):
        a = HourlyEmployee("Max","System Administrator",65.0)
        with self.assertRaises(Exception) as context:
            a.calculate_pay()
        
        self.assertTrue(type(context.exception) in [TypeError,AssertionError])

    def test_compute_pay(self):
        a = HourlyEmployee("Max","System Administrator",65.0)
        a.hours_worked = 20
        self.assertEqual(a.calculate_pay(), Decimal(1300.0), "Pay not correct")
        a.hours_worked = 40
        self.assertEqual(a.calculate_pay(), Decimal(2600.0), "Pay not correct")
        
    def test_compute_pay_with_overtime(self):
        a = HourlyEmployee("Max","System Administrator",65.0)
        a.hours_worked = 60
        self.assertEqual(a.calculate_pay(), Decimal(4550.0), "Pay not correct")
        
    def test_employee_types(self):
        a = HourlyEmployee("Max","System Administrator",65.0)
        b = Employee("Cindy", "Sales Manager")
        self.assertEqual(a.employee_type,"hourly")
        self.assertNotEqual(a.employee_type,b.employee_type)
        
unittest.main(argv=['unittest','TestHourlyEmployee'], verbosity=2, exit=False)

test_compute_pay (__main__.TestHourlyEmployee.test_compute_pay) ...

ok

test_compute_pay_no_hours (__main__.TestHourlyEmployee.test_compute_pay_no_hours) ... 

ok

test_compute_pay_with_overtime (__main__.TestHourlyEmployee.test_compute_pay_with_overtime) ... 

ok

test_create (__main__.TestHourlyEmployee.test_create) ...

ok

test_employee_types (__main__.TestHourlyEmployee.test_employee_types) ...

ok

----------------------------------------------------------------------
Ran 5 tests in 0.001s

OK

<unittest.main.TestProgram at 0x10741df40>

Many programming languages support the concept of an abstract class. Such a class cannot be instantiated on its own and is meant to serve as a base class for other classes. Within the base class, we can declare common behavior and properties for all its subclasses. We can also define behavior that should be implemented by the subclasses such as with calculate_pay(). To formally define an abstract base class in Python, use the abc module.

29.1. Multiple Inheritance#

Multiple inheritance is the ability of a class to inherit from two or more superclasses.

The primary drawback to multiple inheritance is the diamond problem. In the below diagram, suppose classes A, B, and C have all defined a particular method while D has not. Then, when that method is called on an object of class D, which version of the method is used? A’s? B’s? C’s?

Python solves this problem by defining a specific method resolution order. When looking for a method or attribute, Python performs the following search: the object itself, the object’s class, the first parent class, the second parent class, the n^th parent class, and then those parent’s in order.

For example, consider the following set of classes:

class SkilledEmployee:
    def beverage(self): return "water"
    def skill(self):    return "Works hard"

class Programmer(SkilledEmployee):
    def skill(self):    return "Writes Code"

class Statistician(SkilledEmployee):
    def skill(self):    return "statistical analysis"
    
class StoryTeller(SkilledEmployee):
    def beverage(self): return "beer"
    def skill(self):    return "tells stories"
    
class ComputationalDataScientist(Programmer,Statistician):
    def beverage(self): return "Mountain Dew"

class StatisticalAnalyst(Statistician, Programmer):
    def beverage(self): return "tea"

class Presenter(StoryTeller, Programmer, Statistician):
    pass

print("Skills - ")
print("ComputationalDataScientist:", ComputationalDataScientist().skill())
print("StatisticalAnalyst:", StatisticalAnalyst().skill())
print("Presenter:", Presenter().skill())
print("\nBeverages - ")
print("ComputationalDataScientist:", ComputationalDataScientist().beverage())
print("StatisticalAnalyst:", StatisticalAnalyst().beverage())
print("Presenter:", Presenter().beverage())

Skills - 
ComputationalDataScientist: Writes Code
StatisticalAnalyst: statistical analysis
Presenter: tells stories

Beverages - 
ComputationalDataScientist: Mountain Dew
StatisticalAnalyst: tea
Presenter: beer

Each Python class contains a method mro() that returns the list of classes to search to find a particular attribute or method for an object of that class.

ComputationalDataScientist.mro()

[__main__.ComputationalDataScientist,
 __main__.Programmer,
 __main__.Statistician,
 __main__.SkilledEmployee,
 object]

As we look for a skill for a ComputationalDataScientist, the interpreter checks these class definitions

The object itself
The object’s class (class and static methods)
The class’s first parent class - Programmer
The class’s second parent class - Statistician
The interpreter then continues to check the parent’s superclasses in a similar order.

Finding the skill() implementation for StatisticalAnalyst follows the same logic, but its first parent class is Statistician and then Programmer.

Presenter shows that we could inherit from 3 parent classes.

Presenter.mro()

[__main__.Presenter,
 __main__.StoryTeller,
 __main__.Programmer,
 __main__.Statistician,
 __main__.SkilledEmployee,
 object]

29.2. Polymorphism and Duck Typing#

Polymorphism is the ability to call a specific method (send a message) to an object without knowing the receiving object’s actual type. If the receiving object implements that method, then it can respond appropriately. A runtime exception is generated if the receiving object does not implement that method.

The Employee class demonstrates polymorphism within the __str__ method. That method calls the employee_type() method without knowing the exact underlying type of self. The multiple inheritance example demonstrates polymorphism as well.

With Polymorphism, Python programmers can apply the same operation(method call) to different types as long as the method’s name and the number of arguments exist with the receiving type’s definition.

Polymorphism allows methods of the same name to have predictable behavior but allows the underlying class to define the specific behavior independently.

Duck typing is a programming concept used primarily in dynamically typed languages, where the type or class of an object is determined by its behavior (methods) and properties rather than its inheritance or class definition. Duck typing allows for more flexible and extensible code by focusing on what an object can do.

The following code demonstrates polymorphism and duck typing. speak() is called on the animal parameter in the function animal_sound(). We do not know from looking at the code what the Dog.speak() or Duck.speak() is called - that determination is made at runtime based upon the actual type of animal (polymorphism). With duck typing, if an object behaves like a certain type (meaning it has the necessary methods or attributes), it’s treated as an instance of that type, regardless of its actual class or type definition. In this example, the presence of the method speak() effectively becomes a type.

class Dog:
    def speak(self):
        return "Woof!"

class Duck:
    def speak(self):
        return "Quack!"

class Fox:
    def run(self):
        return "Running!"

def animal_sound(animal):
    return animal.speak()

d = Dog()
duck = Duck()
f = Fox()

print(animal_sound(d))    # Output: Woof!
print(animal_sound(duck)) # Output: Quack!
print(animal_sound(f))    # AttributeError 

Woof!
Quack!

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
Cell In[11], line 22
     20 print(animal_sound(d))    # Output: Woof!
     21 print(animal_sound(duck)) # Output: Quack!
---> 22 print(animal_sound(f))    # AttributeError 

Cell In[11], line 14, in animal_sound(animal)
     13 def animal_sound(animal):
---> 14     return animal.speak()

AttributeError: 'Fox' object has no attribute 'speak'

For a fun diversion, What Does the Fox Say? - YouTube

29.3. Mixins#

A popular use case for multiple inheritance is to inherit from a particular class (a “mixin”) that defines well-established methods and attributes (features). Usually, only one feature exists in a “mixin” class. This class does not share methods with any other parent class - this avoids the diamond problem. The inheritance from “mixins” is not an “is a” relationship, but rather “has behavior”.

The methods in “mixin” classes are typically “side” tasks - sometimes generic in nature, such as logging or type conversions. However, the methods can also be specific to the problem domain, adding shared functionality to different classes. For example, a charting library could have mixins to deal with colors and legends.

The below example creates DumpAttributeMixin to print an object’s attributes.

class DumpAttributeMixin:
    def dump(self):
        import pprint
        pprint.pprint(vars(self))
        
class HourlyDumpEmployee(HourlyEmployee, DumpAttributeMixin):
    pass

c = HourlyDumpEmployee("Max","System Administrator","54.76")
c.dump()

{'_Employee__id': 102,
 '_Employee__job_title': 'System Administrator',
 '_Employee__name': 'Max',
 '_HourlyEmployee__hourly_rate': Decimal('54.76'),
 '_HourlyEmployee__hours_worked': None}

help(object)

Help on class object in module builtins:

class object
 |  The base class of the class hierarchy.
 |
 |  When called, it accepts no arguments and returns a new featureless
 |  instance that has no instance attributes and cannot be given any.
 |
 |  Built-in subclasses:
 |      anext_awaitable
 |      async_generator
 |      async_generator_asend
 |      async_generator_athrow
 |      ... and 90 other subclasses
 |
 |  Methods defined here:
 |
 |  __delattr__(self, name, /)
 |      Implement delattr(self, name).
 |
 |  __dir__(self, /)
 |      Default dir() implementation.
 |
 |  __eq__(self, value, /)
 |      Return self==value.
 |
 |  __format__(self, format_spec, /)
 |      Default object formatter.
 |
 |      Return str(self) if format_spec is empty. Raise TypeError otherwise.
 |
 |  __ge__(self, value, /)
 |      Return self>=value.
 |
 |  __getattribute__(self, name, /)
 |      Return getattr(self, name).
 |
 |  __getstate__(self, /)
 |      Helper for pickle.
 |
 |  __gt__(self, value, /)
 |      Return self>value.
 |
 |  __hash__(self, /)
 |      Return hash(self).
 |
 |  __init__(self, /, *args, **kwargs)
 |      Initialize self.  See help(type(self)) for accurate signature.
 |
 |  __le__(self, value, /)
 |      Return self<=value.
 |
 |  __lt__(self, value, /)
 |      Return self<value.
 |
 |  __ne__(self, value, /)
 |      Return self!=value.
 |
 |  __reduce__(self, /)
 |      Helper for pickle.
 |
 |  __reduce_ex__(self, protocol, /)
 |      Helper for pickle.
 |
 |  __repr__(self, /)
 |      Return repr(self).
 |
 |  __setattr__(self, name, value, /)
 |      Implement setattr(self, name, value).
 |
 |  __sizeof__(self, /)
 |      Size of object in memory, in bytes.
 |
 |  __str__(self, /)
 |      Return str(self).
 |
 |  ----------------------------------------------------------------------
 |  Class methods defined here:
 |
 |  __init_subclass__(...) from builtins.type
 |      This method is called when a class is subclassed.
 |
 |      The default implementation does nothing. It may be
 |      overridden to extend subclasses.
 |
 |  __subclasshook__(...) from builtins.type
 |      Abstract classes can override this to customize issubclass().
 |
 |      This is invoked early on by abc.ABCMeta.__subclasscheck__().
 |      It should return True, False or NotImplemented.  If it returns
 |      NotImplemented, the normal algorithm is used.  Otherwise, it
 |      overrides the normal algorithm (and the outcome is cached).
 |
 |  ----------------------------------------------------------------------
 |  Static methods defined here:
 |
 |  __new__(*args, **kwargs) from builtins.type
 |      Create and return a new object.  See help(type) for accurate signature.
 |
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |
 |  __class__ = <class 'type'>
 |      type(object) -> the object's type
 |      type(name, bases, dict, **kwds) -> a new type

29.4. Determining Object Types#

Python has several different ways to test an object’s type:

The buit-in functionisinstance() tests if an object is an instance of a particular type. Notice that since StoryTeller inherits from SkilledEmployee, that e is also a SkilledEmployee. We are maintaining the is a relationship.

e = StoryTeller()
print("isinstance(e,StoryTeller):", isinstance(e,StoryTeller))
print("isinstance(e,Programmer):", isinstance(e,Programmer))
print("isinstance(e,SkilledEmployee):", isinstance(e,SkilledEmployee))

isinstance(e,StoryTeller): True
isinstance(e,Programmer): False
isinstance(e,SkilledEmployee): True

We can also use the built-in function type(), which only checks if the object is that exact type (i.e., it does not consider inheritance).

e = StoryTeller()
print(type(e))
print("Equality to StoryTeller:", type(e) == StoryTeller)
print("Equality to Programmer:",type(e) == Programmer)
print("Equality to SkilledEmployee:",type(e) == SkilledEmployee)

<class '__main__.StoryTeller'>
Equality to StoryTeller: True
Equality to Programmer: False
Equality to SkilledEmployee: False

The built-in function issubclass tests if the class reference is derived from another class or is the same class. The first argument must be a class

print("issubclass(Statistician,Statistician):",       issubclass(Statistician,Statistician))
print("issubclass(Statistician,Programmer):",         issubclass(Statistician,Programmer))
print("issubclass(Statistician,SkilledEmployee):",    issubclass(Statistician,SkilledEmployee))
print("issubclass(Statistician,StatisticalAnalyst):", issubclass(Statistician,StatisticalAnalyst))

issubclass(Statistician,Statistician): True
issubclass(Statistician,Programmer): False
issubclass(Statistician,SkilledEmployee): True
issubclass(Statistician,StatisticalAnalyst): False

Ideally, we do not want to explicitly check an object’s type. We should rely upon Python to use duck typing and polymorphism to take the appropriate behavior. If necessary, we can handle an exception if we call an object that does not implement a particular method.

29.5. Note#

In Python, all objects implicitly inherit from the class object if a parent class is not explicitly defined. This implicit inheritance is object appears as the last item in the mro() calls above. This inheritance hierarchy allows for shared behavior defined among all created objects in Python - such as the ability to get the string representation.

29.6. Suggested LLM Prompts#

Explain the concept of inheritance in object orient programming, where a subclass inherits attributes and methods from a parent or base class. Demonstrate how to create a subclass in Python and how to override or extend methods from the parent class. Include examples of single and multiple inheritance.
Describe the different types of inheritance in Python (single, multiple, and multilevel inheritance) with code examples for each type. Discuss the advantages and potential pitfalls of using multiple inheritance.
Explain the concept of method overriding in Python inheritance. Provide an example where a child class overrides a method from its parent class, and discuss the reasons for overriding methods.
Explain polymorphism, which is the ability of objects to take on many forms. Demonstrate how to achieve polymorphism in Python through method overriding in subclasses. Show examples of how the same method can behave differently based on the object’s class.
Discuss the use of the super() function in Python inheritance. Provide an example where super() is used to call a method in the parent class from a child class. Explain the benefits of using super().
Explain the concept of abstract classes and abstract methods in Python. Discuss the purpose of using abstract classes and provide an example of how to create an abstract class and abstract methods.
Discuss the tradeoffs between inheritance and composition in Python. Provide examples of scenarios where inheritance would be preferable and scenarios where composition (using objects as attributes) would be a better design choice.
Explain the concept of multiple inheritance in Python and discuss the potential issues that can arise, such as the diamond problem. Provide an example of the diamond problem and discuss possible solutions.
Discuss the use of mixins in Python, which are classes designed to provide specific functionality to other classes through inheritance. Provide an example of creating and using a mixin class.

29.7. Review Questions#

What is inheritance in the context of object-oriented programming, why is it useful, and how is it implemented in Python?
How do you create a subclass that inherits from a parent class in Python? Explain the difference from a regular class.
What is the purpose of the super() function when working with inheritance in Python?
What is method overriding, and how is it achieved in Python?
What is the difference between single inheritance, multiple inheritance, and multilevel inheritance?
What is polymorphism in object-oriented programming, and how is it implemented in Python?
What is an abstract class, and how do you define one in Python?
What is the purpose of abstract methods in abstract classes?
What is the diamond problem in multiple inheritance, and how is it resolved in Python?
What are mixins in Python, and how are they used in inheritance?
How can you check if an instance is an instance of a particular class or its subclasses?
Which of these is a common tool that software engineers use to describe the design of their classes?
1. XML inheritance trees.
2. HTML class refinements.
3. CDML hierarchies.
4. UML diagrams.

What will be the output of the following Python code?

class Test:
    def __init__(self):
        self.x = 0

class Derived_Test(Test):
    def __init__(self):
        Test.__init__(self)
        self.y = 1

b = Derived_Test()
print(b.x,b.y)

Syntax error in the code
The program runs fine but nothing is printed
1 0
0 1