[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Packages

From: David Grant
Subject: [Gnumed-devel] Packages
Date: Sun, 22 Feb 2004 02:18:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040207

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

from gnumed.client.python-common import gmDispatcher, gmSignals
from 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, and this in 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 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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]