Inheritance best practice : *args, **kwargs or explicitly specifying parameters

Question

I often find myself overwriting methods of a parent class, and can never decide if I should explicitly list given parameters or just use a blanket *args, **kwargs construct. Is one version better than the other? Is there a best practice? What (dis-)advantages am I missing?

class Parent(object):

    def save(self, commit=True):
        # ...

class Explicit(Parent):

    def save(self, commit=True):
        super(Explicit, self).save(commit=commit)
        # more logic

class Blanket(Parent):

    def save(self, *args, **kwargs):
        super(Blanket, self).save(*args, **kwargs)
        # more logic

Perceived benefits of explicit variant

• More explicit (Zen of Python)
• easier to grasp
• function parameters easily accessed

Perceived benefits of blanket variant

• more DRY
• parent class is easily interchangeable
• change of default values in parent method is propagated without touching other code

Answer 1

Liskov Substitution Principle

Generally you don't want you method signature to vary in derived types. This can cause problems if you want to swap the use of derived types. This is often referred to as the Liskov Substitution Principle.

Benefits of Explicit Signatures

At the same time I don't think it's correct for all your methods to have a signature of *args, **kwargs. Explicit signatures:

• help to document the method through good argument names
• help to document the method by specifying which args are required and which have default values
• provide implicit validation (missing required args throw obvious exceptions)

Variable Length Arguments and Coupling

Do not mistake variable length arguments for good coupling practice. There should be a certain amount of cohesion between a parent class and derived classes otherwise they wouldn't be related to each other. It is normal for related code to result in coupling that reflects the level of cohesion.

Places To Use Variable Length Arguments

Use of variable length arguments shouldn't be your first option. It should be used when you have a good reason like:

• Defining a function wrapper (i.e. a decorator).
• Defining a parametric polymorphic function.
• When the arguments you can take really are completely variable (e.g. a generalized DB connection function). DB connection functions usually take a connection string in many different forms, both in single arg form, and in multi-arg form. There are also different sets of options for different databases.
• ...

Are You Doing Something Wrong?

If you find you are often creating methods which take many arguments or derived methods with different signatures you may have a bigger issue in how you're organizing your code.