Separate modules is good. Separate directories for anything
other than big programs (say 20 or more files?) is more hassle
than its worth. The files are better kept in a single directory
IMHO. The exception being modules designed for reuse...
It just makes life simpler!
Ive tried to be hyper organized and added my dirs in /usr/lib/python2.3/site-packages/mypath.pth
/home/dave/mygg/gg1.3/live_datad /home/dave/mygg/gg1.3/logger /home/dave/mygg/gg1.3/utils /home/dave/mygg/gg1.3/datacore /home/dave/mygg/gg1.3 /home/dave/mygg/gg1.3/configs
This works OK but I sometimes have to search around a bit to find where the modules are.
Probarby part of the problem is I tend to write lots of small modules, debug them & then import them into one controlling script, It works OK but I start to drown in files, eg my live_datad contains ...
exact_sleep.py garbage_collect.py gg ftsed.e3p html_strip.py live_datad.py valid_day.pyc
exact_sleep.pyc garbage_collect.pyc gg ftsed.e3s html_strip.pyc valid_day.py
When I get more experienced I will try & write fewer, bigger modules :-)
It's just a guess from the filenames, but it looks like your live_datad package (directory) contains everything needed by live_datad.py. I would like to suggest a different organization.
I tend to organize packages around a single functional area, and by looking at the dependencies of the modules in the package on other packages.
For example, in my current project some of the packages are:
- common.util - this is a catchall for modules that are not specific to this application, and don't depend on any other packages
- common.db - low-level database access modules
- cb.data - application-specific database access - the data objects and data access objects that the application works with
- cb.import - modules that import legacy data into the application
- cb.writer - modules that generate files
- cb.gui - GUI components
- cb.app - application-level drivers and helpers
Anyway, the point is, if you organize your modules according to what they do, rather than by who uses them, you might make a structure that is less chaotic.
HTH Kent _______________________________________________ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
