[Fwd: Re: Multiple test cases and the splitting up of large modules.] -- March 08, 2007 - 11:11

--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK             Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx                   Fax  +44-113-2331407
-------------------------------------------------------------------

--- Begin Message ---

• To: Edward d'Auvergne <edward.dauvergne@xxxxxxxxx>
• Date: Thu, 08 Mar 2007 10:04:41 +0000
• Message-id: <45EFDFB9.4050700@bmb.leeds.ac.uk>
• References: <E1HO9rU-0004g2-14@subversion.gna.org> <45EBEA6A.7030809@bmb.leeds.ac.uk> <7f080ed10703052357i7fc20379n835048c0cc3c84c1@mail.gmail.com> <45ED2A08.6090207@bmb.leeds.ac.uk> <1173174583.8066.223.camel@mrspell> <1173248473.29411.21.camel@pc172-31-2-63.biochem.unimelb.edu.au> <45EFC94F.6000101@bmb.leeds.ac.uk> <7f080ed10703080116p393d302er1ba0cd89f1509e71@mail.gmail.com>
• User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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

regards
gary

--
-------------------------------------------------------------------
Dr Gary Thompson
Astbury Centre for Structural Molecular Biology,
University of Leeds, Astbury Building,
Leeds, LS2 9JT, West-Yorkshire, UK             Tel. +44-113-3433024
email: garyt@xxxxxxxxxxxxxxx                   Fax  +44-113-2331407
-------------------------------------------------------------------

--- End Message ---