Re: Organisation of python classes and their methods

Discussion in 'Python' started by Peter Otten, Nov 2, 2012.

  1. Peter Otten

    Peter Otten Guest

    Martin Hewitson wrote:

    > On 2, Nov, 2012, at 09:00 AM, Peter Otten <> 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):

    class SpecialTimeSeries(BaseTimeSeries, SpecialStats):

    > 'abs'

    > 'zeropad'

    You are not perchance reimplementing numpy?

    > More thinking needed, clearly.

    That will never hurt. Well, almost:,1942/

    Peter Otten, Nov 2, 2012
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Rubin
    Steven D'Aprano
    Nov 3, 2012
  2. Peter Otten
    Peter Otten
    Nov 2, 2012
  3. Robert Kern
    Robert Kern
    Nov 2, 2012
  4. Frank Millman
    Frank Millman
    Nov 2, 2012
  5. Ulrich Eckhardt
    Ulrich Eckhardt
    Nov 2, 2012

Share This Page