Python program organization

[Harry George]

Derek W <whitedw at NOSPAMcox.net> writes:

> Hello all,
> 
> I have a few questions about the best way to organize a large Python
> program.  This would be a large program with a GUI interface, too
> large to be put all in one script file by any sane person.  I was
> wondering about how a Python programmer should organize the multiple
> python source files that will be needed by their program.  Is it
> proper to break the program up into modules and put all of the modules
> in a package even if the modules would be of little or no use to
> others (such as the program specific GUI code)?  Would this package
> then go under Python's site-packages directory when the program is
> installed?  Would distribution of a program like this use distutils?
> 
> Thank you,
> Derek

1. General purpose

You should first think "model-view-controller", where the model is a
GUI-free compute engine which knows your persistant data.  Then build
"view" modules which call the model's API.  This should be bundled
with testsuites, convenience scripts, documentation, etc.  These can
all go in the same package, and that in turn can be bundled using
distutils.  Distutils in turn installs the package into site-packages.

For a utility which sets up a project, see:
http://www.seanet.com/~hgg9140/comp/mkpythonproj-1.5/doc/mkpythonproj.help

2. Larger

As projects get larger, you will find there are several "models".
E.g., for translations between various COTS tools.  In that case, make
a separate package for each model (e.g., for the reader/writer adaptor
for each data format), and then another package for the project which
ties them together.  The idea is to reduce unneeded cohesion -- make
the packages as isolated as you reasonably can so they are reusable in
other contexts.

3. Config controlled

If you have several variants of the packages, e.g., under CVS, then
you don't want to put them all in site-packages.  Instead, check out
an internallly-consistent set of packages to a directory (e.g.,
"alpha", "beta", "prod").  Then, to assure the "imprts" find the right
modules and the right python version is run, make execution scripts
which do:

    export PYTHONPATH=<path to working dir>/mypackage01:
                      <path to working dir>/mypackage02:
                      ${PYTHONPATH}

    PY=/usr/local/python2.3
    
    ${PY} <path to main script>  <arguments as needed>



-- 
harry.g.george at boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 342-0007