Organisation of python classes and their methods

[Peter Otten]

Martin Hewitson wrote:

> 
> On 2, Nov, 2012, at 09:00 AM, Peter Otten <__peter__ at web.de> wrote:
> 
>> Martin Hewitson wrote:
>> 
>>> Dear list,
>>> 
>>> I'm relatively new to Python and have googled and googled but haven't
>>> found a reasonable answer to this question, so I thought I'd ask it
>>> here.
>>> 
>>> I'm beginning a large Python project which contains many packages,
>>> modules and classes. The organisation of those is clear to me.
>>> 
>>> Now, the classes can contain many methods (100s of data analysis
>>> methods) which operate on instances of the class they belong to. These
>>> methods can be long and complex. So if I put these methods all in the
>>> module file inside the class, the file will get insanely long. Reading
>>> on google, the answer is usually "refactor", but that really doesn't
>>> make sense here. It's just that the methods are many, and each method
>>> can be a long piece of code. So, is there a way to put these methods in
>>> their own files and have them 'included' in the class somehow? I read a
>>> little about mixins but all the solutions looked very hacky. Is there an
>>> official python way to do this? I don't like having source files with
>>> 100's of lines of code in, let alone 1000's.
>> 
>> You googled, found the right answer ("refactor"), didn't like it and are
>> now looking to cure the symptoms of the original problem?
>> Seriously, a good editor can deal with a long source file, but a class
>> with hundreds of methods will bring trouble to any old brain.
> 
> Well, here we disagree. Suppose I have a class which encapsulates
> time-series data. Below is a list of the absolute minimum methods one
> would have to process that data. That's close to 100 already before even
> having any specialised methods for dealing with the data.  Each of these
> methods will have maybe 20 lines of documentation. That's 2000 lines
> already. And what if someone wants to extend that class to add their own
> processing methods? 

from timeseries import TimeSeries

class MyTimeSeries(TimeSeries):
    def average():
        # specialised implementation

> It would a maintenance nightmare for them to edit the
> actual class file, which they would then have to repeat each time a new
> version of the 'official' class file is released.

Patient: Doctor, it hurts when I ... 
Doctor: Then don't do that.

> So maybe some rethinking of this design is needed to handle this
> 'limitation' of python. Perhaps grouping the processing algorithms into
> methods of processing classes, then pass the data objects to these
> methods. But somehow I don't like that. I have the feeling these methods
> would end up peppered with things like:
> 
> if this data type, do this
> else if this data type, do this
> else ....
> 
> normally this would be solved by overloading methods in different data
> subclasses.

You could ask your TimeSeries for the appropriate Statistics subclass

stats = ts.get_stats()
print stats.mean()

where get_stats() is a classmethod that returns an object that provides 
min(), max(), average() etc.
 
Another approach are mix-in classes:

class Stats:
    def min(): ...
    def average(): ...

class SpecialStats(Stats):
    def min(): return 42

class TimeSeries(BaseTimeSeries, Stats):
    pass

class SpecialTimeSeries(BaseTimeSeries, SpecialStats):
    pass

>     'abs'
[...]
>     'zeropad'

You are not perchance reimplementing numpy?

> More thinking needed, clearly.

That will never hurt. Well, almost:

http://www.theonion.com/articles/beaver-overthinking-dam,1942/

:)