[Gnumed-devel] Packages

[David Grant]

Regardless of installation stuff, I think we should go ahead and switch 
to a python package system, where modules are imported like this (using 
gmAllergies.py as an example):

from gnumed.client.python-common import gmDispatcher, gmSignals
from gnumed.client.python-common.business.gmClinicalRecord import 
gmClinicalPart

instead of:

import gmDispatcher, gmSignals
from gmClinicalRecord import gmClinicalPart

Reasons are:

1. Basically for the purpose of getting rid of the entire get_base_path 
thing in gnumed.py, and this in gnumed.py as well:

# manually extend our module search path
       sys.path.append(os.path.join(appPath, 'wxpython'))
       sys.path.append(os.path.join(appPath, 'python-common'))
       sys.path.append(os.path.join(appPath, 'business'))

2. For the additional reason, of now having the ability to import 
everything in a package, like so:

from gnumed.client.python-common import *

I don't think you have the option currently because there are were no 
__init__.py files before and hence no packages.  This is usually not a 
good idea because it obscures where names are imported from.  But in 
some cases it can be used.

3. Tells people what the imported modules relate to:

When I see this:

import gmDispatcher, gmSignals
from gmClinicalRecord import gmClinicalPart

as a new developer, I might like to know where these are coming from.  I 
may want to edit one of the functions defined in the gmDispatcher 
module.  However I have no idea where it is.  It turns out it is in the 
python-common directory, along with gmSignals.  But gmClinicalRecord is 
in the business directory.  So I have to hunt around for both of these, 
which is a big pain.  Given an unfamiliar name one might have to look in 
several directories to find it.

4. You obviously find it convenient to group the modules by directory, 
so not carry it through to the modules?

5. It makes it clearer what the modules are.  I may have no idea what 
gmClinicalRecord is on its own.  But if I see it as 
gnumed.client.business.gmClinicalRecord that gives me a better idea of 
what it is.  Helpful again for new and old developers alike to know 
what's going on.

6. If you want to have a module with the same name in each directory 
business and python-common, let's say, you can't access both, because 
there are both in the sys.path.

The only disadvantage is that it makes import statements longer, but it 
shouldn't be that bad.  I think Karsten already agreed to do this, when 
he asked for volunteers, but I just want to make clear WHY it is good to 
do this, because:

python-common has to be renamed to pythoncommon or something else, 
because dashes aren't supported in python package names or any python 
names for that matter.  As long as no one has uncommitted changes, it 
should be an easy change.

Please send any comments to the list.  Thank you.

--
David J. Grant
M.A.Sc. Candidate in Electrical Engineering
a-Si and Integrated Circuits Lab
University of Waterloo
Room DC3707
519-888-4567 x2872
http://www.eng.uwaterloo.ca/~djgrant