On 3/8/07, Gary S. Thompson <[EMAIL PROTECTED]> wrote:
---------- Forwarded message ---------- From: "Gary S. Thompson" <[EMAIL PROTECTED]> To: Edward d'Auvergne <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
_______________________________________________ relax (http://nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
