Kent Johnson wrote:
Dave S wrote:
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.
Spot on
I have been getting in a muddle, html_strip.py, strips HTML, mines for data & when it finds specific patterns returns a dictionary containing them.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
However I also use one of its functions in a utility convert_data.py reading in archived semi-processed HTML files. This cross dependance has occured several times and is getting messy, yours is an interesting approach, Its started me thinking...
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
_______________________________________________ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
