module location

[Darrell]

Two approaches I know of:

Define a module to hold an interface to some component.

abstractDB.py

It imports the specific version of db and provides any glue. All access to
DB is via abstractDB which can be imported by a module deeply buried in some
package.

Remindes me of this sort of thing:
        import myPackage.myMod
        myMod=myPackage.myMod

Or:

pass an instance that provides the desired interface to the lower level
packages. This is the most common and probably most flexible.

--
--Darrell
Boudewijn Rempt <boud at rempt.xs4all.nl> wrote in message
news:7sj6ii$1jc$1 at essle.valdyas.org...
> I'm working on my first large(ish) python project - a linguistics database
> application - and I'm trying to keep my sources ordered, and my layers
> separated, and having some problems doing it right.
>
> So I've got a database access module, a middleware module, an abstract
> gui module, and finally the actual application, which binds the gui to
> the middleware. Currently, I've laid my project out as follows:
>
> lng (contains start script, readme, on so on)
>   /kuralib (contains the actual app
>    /db   (database layer)
> /gui  (gui widgets)
> /lng  (middleware - table and record objects)
>
> But now my problem is that the middleware also needs to access the db
> layer - as does the application itself (for connecting and so on). What's
> the received wisdom in this case? Do I make the db layer a separate
> module which I install in /usr/lib/python/site-packages, or do I make
> db a submodule of lng, and pass the connection on to the main application?
>
> I really want to keep everything as separate as possible, to ease the
> task of people who want to port the application to windows - something
> I won't be doing myself.
>
> --
>
> Boudewijn Rempt  | http://www.xs4all.nl/~bsarempt