Where to put the separation between a stateful object and a stateless calculation in Python?

Question

Which of the following code snippets is the most "pythonic"? The calculation is trivial in this example but could be assumed to be complex in real life.

class A(object):
    """Freely mix state and calcs - no good I presume"""
    def __init__(self, state):
        self.state = state

    def calc_with_state(self, x):
        return (self.state + x)**2

or

class B(object):
    """Separate state from calc by a static method"""
    @staticmethod
    def inner_calc(u, v):
        return (u + v)**2

    def __init__(self, state):
        self.state = state

    def calc_with_state(self, x):
        return B.inner_calc(self.state, x)

or

class C(object):
    """Break out the calculation in a free function"""
    def __init__(self, state):
        self.state = state

    def calc_with_state(self, x):
        return outer_calc(self.state, x)

def outer_calc(u, v):
    return (u + v)**2

Answer 1

I think it depends on your particular project. Is cal_with_state only applicable to this particular class or is the method needs to be shared among many different objects? Do different classes share it?

There is nothing more or less pythonic about any of this approaches, use the one that will satisfy your project. DRY is beyond pythonicity.

Answer 2

Personally I would say it depends on resusability. If the calculation is one that might be used with other objects (as it does look to be) then the third example is the most reusable. If the calculation is completely tied to the object or would never be reused then the first example. I'd say the second example is wrong in most cases.

Answer 3

Factoring out the calculation, whether in a static or global method doesn't offer any benefit with regards to the state awareness. The only slight advantage is that the code explicitly shows which of the object's stateful properties are taken into account in the calculation (show at the level of the function call, rather than having to be read within the logic of the method in the class A)

There may be other advantages to introducing stateless (static, global) or instance methods:

• reusability
• code readability and management at large

but as said, these constructs do not help with regards to state management per-se. The A approach seems quite legitimate (and pythonic) to me. Indeed David Berger beat us to it, in reminding us that...

Flat is better than nested!

.

Answer 4

What is wrong with A? It does the calculation in one place only and does not modify the state so calc_with_state is a method that does not change state so is a 'simple' behaviour. If the state was complex it stops a large number of parameters being passed into the calculation function.

However if the calculation can be written taking the state as a parameter (as in C) then you can separate out the calculation. benefits here include being able to rues this calculation on data not in the class C and also you can use the function as data passed to C so calc_with_state can be made to call different calculation functions

I can't see B having any benefits as inner_calc does not make use of the class and so could just as well be a free function.

So I would probably write it as A first and then if wanting to reuse the calculation, make the class use different calculations or just if the code of the calculation got too big you could refactor into class C

Answer 5

As written, A, by a longshot. The issue, quite simply, is

Flat is better than nested.

Look: separating state from calculations is a good design principle, but it doesn't mean what you think, at least not what I can infer you think from this example. We want to make sure that state doesn't change in order to complete calculations if that state isn't going to be reinitialized on the next calculation. If state is read-only with respect to some particular calculation, there's no stylistic compulsion to redirect around it so that you don't directly read it. That is, unless the calculation and the state are sufficiently complex to need separate unit testing. Then, by all means, B or C will be preferred, but only if it is really that much easier to create values for u than to instantiate fresh instances of A.