Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Peter Otten <__peter__@web.de>
Subject: Re: Organisation of python classes and their methods
Date: Fri, 02 Nov 2012 10:17:16 +0100
Organization: None
References: <B16BD7AC-F860-4A30-A08D-A0235CC25F20@mac.com> <k6vuis$j5b$1@ger.gmane.org> <E4CF83CA-179F-4FD5-A1CB-D25060C568A4@mac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/4.7.3
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.3190.1351847843.27098.python-list@python.org>
Lines: 105
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32608

Martin Hewitson wrote:

> 
> On 2, Nov, 2012, at 09:00 AM, Peter Otten <__peter__@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/

:)