Page 1 of 4
Python supports multiple inheritance which can be scary, but before you master it you have to know how single inheritance works - no less scary! This extract is from my new book published on July 9th with the subtitle "Something Completely Different".
Everything is an Object
Is now available as a print book: Amazon
- Hello Python World
- Variables, Objects and Attributes
- The Function Object
Extract - Function Objects
- Scope, Lifetime and Closure
Extract - Local and Global ***NEW
- Advanced Functions
Extract - Decorators
- Class Methods and Constructors
- Inside Class
- Advanced Attributes
Extract - Properties
- Custom Attribute Access
- Single Inheritance
- Multiple Inheritance
- Class and Type
- Type Annotation
- More Magic - Operator Overloading
Now we come to the big topic of inheritance, only in Python it isn’t such a big deal.
We already have the basic mechanism whereby one object passes on the responsibility for providing functions wrapped as methods in the class. The same mechanism provides for inheritance. There some things that Python does differently even for simple inheritance. In particular how the inheritance chain is searched and exactly how the super() built-in function works is both subtle and powerful. Then there is the small matter of how classes inherit instance attributes i.e. how to call the superclass __init__.
Beyond this Python is special among modern programming languages in that it provides multiple inheritance. This is something that is generally less well understood and we need to examine it in detail in the next chapter. Even if you plan to keep away from multiple inheritance, knowing how it works and what it gives you can make you see single inheritance in a different light.
Python’s inheritance mechanisms might look like what you find in other languages but they aren’t the same at all.
At its most basic inheritance is about code reuse.
Suppose you have a class that defines a particular data structure, a List say, and you want to create a class that has some extra features – a sortedList, say. It is fairly obvious that sortedList is going to have most of the attributes of List, and hence most of the code is going to be the same.
How best to implement it?
Before object-oriented programming and the use of inheritance in particular, the usual method was to use copy-and-paste. That is, the code to be modified was simply copied and edited. This usually involved a lot of work in renaming variables consistently to avoid name clashes between the old code and the copied code. It also has the disadvantage that much of the code is duplicated in the running program.
Inheritance was initially introduced as a way of reusing code. A class that inherited from another class started off with all of that class’s attributes. You could then add attributes and modify inherited attributes to make the new class different from the original class. The idea was that you reused as much of the code as possible.
This sounds as if it is much better than copy-and-paste inheritance but it introduces some new problems.
For example, if an original class is modified then all of the classes that inherit it also change. If the changes are radical it can make the inheriting classes fail. This is known as the problem of the “brittle” base class. To minimize this problem, object-oriented programming introduced design philosophies that emphasized the idea that what happened inside a class was only a matter for the class and not for the outside world.
This is essentially the idea of encapsulation, one of the main principles of object-oriented programming. Some languages enforce encapsulation and won’t let code that is outside of the class access anything inside a class unless it is via method calls and parameters. In this view a method only promises to do something and makes no promises about how it does something.