How Does Overriding Work in Python?

Overriding is simply defining a method with the same name in a subclass. The subclass version is used whenever the method is called on an instance of the subclass.

class Parent:
    def greet(self):
        return "parent greeting"


class Child(Parent):
    def greet(self):
        return "child greeting"

    def greet_parent(self):
        return super().greet()


child = Child()
print(child.greet())            # child greeting
print(child.greet_parent())     # parent greeting
print(isinstance(child, Parent))   # True

There is no special syntax for overriding — a method of the same name is enough. The parent implementation is still there and can be reached through super().

The right way to reach the parent is super().greet(), and it is important to use super() rather than naming the parent class directly. super() looks up the next class in the method resolution order of the current instance, which means it stays correct if the class is later combined with a mix-in or re-parented. Writing Parent.greet(self) hard-codes the parent into the child and breaks as soon as the hierarchy changes.

The isinstance check at the end is worth mentioning: an overridden method does not change the object's type relationship. A Child is still a Parent, which means code that expects a Parent can accept a Child without knowing anything about the override.

There are two ways, and they differ in how they resolve the parent.

class Parent:
    def describe(self):
        return "parent"


class Child(Parent):
    def describe(self):
        return "child"

    def both(self):
        return f"{self.describe()} + {Parent.describe(self)}"

    def both_super(self):
        return f"{self.describe()} + {super().describe()}"


child = Child()
print(child.both())          # child + parent
print(child.both_super())    # child + parent

Both produce the same result here, but they are not equivalent in general. Parent.describe(self) names the parent class explicitly, so it always runs the Parent implementation no matter where Child sits in the hierarchy. super().describe() looks up the next class in the method resolution order of the actual instance, so if Child is combined with a mix-in, super() would reach the mix-in instead.

There is a third reason to prefer super(). Calling Parent.describe(self) directly breaks in a cooperative hierarchy, because it skips the rest of the chain — the other classes in the MRO never get a chance to contribute, and any state they were supposed to initialise is left unset.

The rule to give in an interview is simple: use super() when you want to extend the parent behaviour, and reach for the explicit class name only when you deliberately want to bypass the chain. In ordinary single-inheritance code they look the same, which is why the difference is easy to miss until a mix-in appears.

Overriding in Python is just defining a method in a subclass with the same name as one in the parent. The subclass version is found first during attribute lookup, so it runs. There is no keyword involved and no compiler check — it works because the lookup order puts the subclass before the parent.

Overloading is a different idea and Python does not do it in the way Java or C# do. There, overloading means several methods with the same name but different parameter lists, and the compiler picks one based on the argument types. Python has a single name resolution rule, so you define one function and it accepts whatever the arguments happen to be. The equivalent flexibility is achieved with default arguments, *args and **kwargs, or with the typing.overload decorator, which exists purely for type checkers and does nothing at runtime.

The distinction matters in interviews because people use the words interchangeably. Overriding is a subclass replacing a parent's method, and it exists to specialise behaviour. Overloading is one name serving several signatures, and it exists to handle different argument shapes.

Two practical notes about overriding. The return type is not constrained — a child method may return something different from its parent, which is why some designs treat a changed return type as a bad override. And if the parent's __init__ needs to run, the child must call super().__init__ explicitly, because Python does not call parent initialisers automatically. Forgetting that call leaves the object half-built, and the error often shows up much later as a missing attribute.