Maintain explicit method signatures and LSP : dealing with extra arguments in Python

Question

I'd like to share a OOP conception problem. My code is written in Python. Here is a first non-valid code snippet that illustrates my problem.

Snippet 1

class Model(ABC):
    @abstractmethod
    def f(self, x: float, *args: float) -> float: ...


class ModelA(Model):
    def f(self, x: float) -> float:
        # arbitrary operation to illustrate
        return x + 1


class ModelB(Model):
    def __init__(self, baseline: Model):
        self.baseline = baseline

    def f(self, x: float, covar: float, *args: float) -> float:
        # arbitrary operation to illustrate
        return x * covar + self.baseline.f(x, *args)


def one_future_function(model: Model, x, *args):
    return model.f(x, *args)


modela: Model = ModelA()
modelb: Model = ModelB(modela)

print(one_future_function(modela, 1))
print(one_future_function(modelb, 1, 2))

From a design perspective, I understand that this code does not adhere to type rules, specifically the Liskov Substitution Principle (LSP). Although Python allows it to run, I care about design principles and do not want to keep this code. With my current knowledge and my specifications (more details at the end), the only valid alternative I can think of in Python is the following, but I am not satisfied with it either.

Snippet 2


class Model(ABC):
    @abstractmethod
    def f(self, x: float, *args: float) -> float: ...


class ModelA(Model):
    def f(self, x: float, *args : float) -> float:
        return x + 1


class ModelB(Model):
    def __init__(self, baseline: Model):
        self.baseline = baseline

    def f(self, x: float, *args: float) -> float:
        covar = args[0]
        return x * covar + self.baseline.f(x, *args[1:])

Why am I not satisfied? Because now covar is hidden from the signature in ModelB, and in ModelA, there are still *args that are not used and won’t be expected in the signature. This would be confusing for users of ModelA objects.

Formally speaking, my problem is that sometimes the f method should have “extra” arguments like covar in Snippet 1. Keeping the signature explicit is important because future users of the software would expect f to have “covar” sometimes (and maybe other arguments) and sometimes only x. I’m hiding the details, but the main reason is to keep the code as close as possible to some mathematical formulas. Originally, the idea to rely on *args is to use the unpacking operator trick when Model object can composed of other Model object. Then, extra arguments are propagated and consumed by each baseline component.

I’m looking for another approach that satisfies typing rules and my desire to have explicit method signatures in case there are extra arguments. Additionally:

If possible, I’d like an approach that does not create another base class Model for objects requesting f with x and extra arguments. In my case, extra arguments can vary a lot, so I think it would multiply the number of possible base class variations.
I want to ensure that methods must be implemented in derived Model classes at compile time. That’s why I used an abstract base class (plus inheritance is important because I need to access other crucial mechanisms I put in the Model class).
Note that x is always in the signatures and common to all concrete methods.
I don’t want to rely on any particular library.
I don't want to rely on **kwargs alternatives because I can't name those extra arguments when they exist. ModelB can be composed of one baseline and that baseline can potentially expect extra arguments having common mathematical names : e.g. if modelb = ModelB(ModelB(ModelA())), then modelb.f(2, covar=..., covar=...) would obviously fail

If you think I misunderstand some OOP principles, please explain what I’m missing and provide additional resources. I’m continuously learning.

Thanks in advance! :)

I also tried a alternative where I splitted Model operations in another class. Let's call it Function.

class Function(ABC):
    @abstractmethod
    def f(self, x: float) -> float: ...

    def add_args(*names : str):
        '''allows to add extra arguments treated like attributes'''


class FunctionA(Function):
    def f(self, x: float) -> float:
        # arbitrary operation to illustrate
        return x + 1


class FunctionB(Function):
    def __init__(self, baseline: Function):
        self.baseline = baseline
        self.add_args("covar")

    def f(self, x: float) -> float:
        # covar is now a attribute thanks to add_args method (not decribed here)
        # the value is set in Model
        return x * self.covar + self.baseline.f(x)

class Model:
    def __init__(self, function : Function):
        self.function = function

    def f(self, x : float, *args : float):
        # a setter not described here that returns error if args are expected in function
        self.function.args = args 
        return self.function.f(x)


modela = Model(FunctionA())
modelb = Model(FunctionB(FunctionA())

modela.f(1) # ok
modelb.f(1, 2) # ok
modelb.f(1) # Error : covar value is required

The problem with this alternative is that every time a contributor wants to add a new model, he would have to create a Function object and pass it to Model. That's not intuitive. In addition, covar does not exist in any method signature. I also pass on the details of add_args but it adds complicated lines of code relying and Python magic methods. It worked but it may be risky in terms of maintenance and harder to explain to other contributors.

Maintain explicit method signatures and LSP : dealing with extra arguments in Python

Answers (1)

Related Questions