[Tutor] Python structure advice ?
Kent Johnson
kent37 at tds.net
Fri Dec 17 23:30:38 CET 2004
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
More information about the Tutor
mailing list