[Tutor] Python structure advice ?

[Kent Johnson]

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. 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