Organisation of python classes and their methods

[Martin Hewitson]

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? 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.

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.

More thinking needed, clearly.

Martin



    'abs'
    'acos'
    'asin'
    'atan'
    'atan2'
    'average'
    'cohere'
    'conv'
    'corr'
    'cos'
    'cov'
    'cpsd'
    'detrend'
    'dft'
    'diff'
    'downsample'
    'exp'
    'export'
    'fft'
    'fftfilt'
    'filter'
    'filtfilt'
    'find'
    'heterodyne'
    'hist'
    'imag'
    'integrate'
    'interp'
    'join'
    'le'
    'lincom'
    'ln'
    'load'
    'log'
    'log10'
    'lscov'
    'max'
    'mean'
    'median'
    'min'
    'minus'
    'mode'
    'mpower'
    'mrdivide'
    'mtimes'
    'ne'
    'norm'
    'or'
    'plot'
    'plus'
    'polyfit'
    'power'
    'psd'
    'rdivide'
    'real'
    'resample'
    'rms'
    'round'
    'save'
    'scale'
    'search'
    'select'
    'sin'
    'smoother'
    'sort'
    'spectrogram'
    'split'
    'sqrt'
    'std'
    'sum'
    'sumjoin'
    'svd'
    'tan'
    'tfe'
    'timeaverage'
    'times'
    'timeshift'
    'transpose'
    'uminus'
    'upsample'
    'zeropad'