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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4