On 3/8/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
---------- Forwarded message ----------
From: "Gary S. Thompson" <garyt@xxxxxxxxxxxxxxx>
To: Edward d'Auvergne <edward.dauvergne@xxxxxxxxx>
Date: Thu, 08 Mar 2007 10:04:41 +0000
Subject: Re: Multiple test cases and the splitting up of large modules.
Edward d'Auvergne wrote:
> On 3/8/07, Gary S. Thompson <garyt@xxxxxxxxxxxxxxx> wrote:
>
>> Edward d'Auvergne wrote:
>>
>> >On Tue, 2007-03-06 at 09:49 +0000, Chris MacRaild wrote:
>> >
>> >
>> >>On Tue, 2007-03-06 at 08:44 퍍㐙ꫲ S. Thompson wrote:
>> >>
>> >>
>> >>>Edward d'Auvergne wrote:
>
>
> [ snip ]
>
>> >As for splitting up large modules such as the 66 method, 5701 line
>> >'specific_fns/model_free.py' file, I've been playing around with a few
>> >ideas. I have committed to the 1.3 repository line a change which does
>> >not affect program operation in any way but lays down a foundation for
>> >the breaking up of the model_free.py file
>> >(https://mail.gna.org/public/relax-commits/2007-03/msg00029.html). This
>> >change introduces the directory 'specific_fns/model_free/' while still
>> >retaining the module namespace of 'specific_fns.model_free' by using
>> >import statements in the directory's '__init__.py' file. I've borrowed
>> >this concept from the Python site-packages, especially the Numeric and
>> >scipy modules.
>> >
>> note numeric and scipy (especially) do carry some baggae and have code
>> bases which are known to be 'tricky'
>
>
> This usage of __init__.py to populate the module corresponding to the
> directory with objects and methods appears to be quite a standard
> thing though. Looking again through the site-packages, other code
> which uses this technique include pygtk, psyco, zope, twisted, Pyrex,
> etc. Scientific Python doesn't use the technique and that would be
> one of the most complicated packages for understanding it's data
> structures and modules and what needs to be imported.
>
> Edward
Hi Ed
I guess what i am saying is the fact there is precedent for the use
of __init__.py to munge module layouts doesn't mean that it is a good
thing. Most of the libraries that use it do so because they have large
user bases and the user bases are the programmer (most of these are
libraries rather than programs)and so backwards compatability becomes
very important. However, in our case with a developer base of 4 and no
one using the code base as a library we can be far more consistent in
having the disk layout of files and the module structure mirror each other
I think I've struck that balance with the setup of the 'data'
directory/module. Have a look at file 'data/__init__.py'
corresponding to the 'data' module which contains the 'Data' class and
the file 'data/pipe_container.py' corresponding to the
'data.pipe_container' module which contains the 'PipeContainer' class.
The PipeContainer is also located in the 'data' module because of its
import but that is solely so that the Data class can use it.
PipeContainer should be imported from 'data.pipe_container' and not
'data'.
In the case of the 'specific_fns/model_free' directory/module, things
could be a bit different. The aim would be to break
'specific_fns/model_free/model_free.py' into multiple modules within
the 'specific_fns/model_free' directory. '__init__.py' could then
import all the functions or classes into the 'specific_fns.model_free'
module namespace. I say could because this is only an idea which may
or may not turn out to have benefits. One benefit - less typing - may
be the simplification of the specific function setup code in
'specific_fns/specific_setup.py'. This isn't much of a benefit though
and a counter example is that the function
'self.relax.specific.model_free.molmol.macro()' in that file. The
current benefit is that the module 'specific_fns.model_free' appears
unchanged to the rest of relax. The module changes could easily be
accommodated for though! Even if you had all of the
'specific_fns.model_free.molmol' functions imported into
'specific_fns.model_free', you could still import them from
'specific_fns.model_free.molmol' rather than
'specific_fns.model_free'. In summary the benefits I can currently
envisage are weak. Therefore I'm happy to drop the idea :)
Cheers,
Edward
P.S. The breaking up of the model-free module will probably require
the conversion of the class methods into functions. This will break
all of the little benefits I described above anyway.
Re: [Fwd: Re: Multiple test cases and the splitting up of large modules.]