Martin Hewitson wrote:
>
> On 2, Nov, 2012, at 09:00 AM, Peter Otten <__pete...@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/
:)
--
http://mail.python.org/mailman/listinfo/python-list
