Hello all, I've read a number of the python books, and several online tutorials about modules and packaging, but not one addresses this issue, so I thought I'd ask here...
I am building a library for use in an internal project. This library is the client side interface to a REST-ful service that provides access to parts of our accounting database. BUT, we are pretty sure that the accounting database and hence the service implementation will change in the future. So, I want to design a generic (abstract) api for fetching various info from the accounting db, but I want to isolate the specific details into a module/package that can be changed in future (and co-exist with the old one). I've designed a generic api class, with functions to fetch the various info into python data structures (mostly lists of dictionaries, some just single values). And I've got an interface-specific version that follows that same api, and which is derived from the generic api. I'm a bit unclear on the best way to implement the module and package. Here's the directory structure that I've got so far: project <dir> top level directory setup.py company <dir> eventually, we'll have other modules __init__.py error.py some classes that will be used in all log.py modules acctdb <dir> the acct db interface directory __init__.py api.py the abstract class def (derived from object) specific.py the specific implementation, derived from the api base class For arguments sake, let's call the base class (defined in api.py) 'BaseClass', and the specific implementation 'SpecificClass(BaseClass)' So, in the acctdb/__init__.py, do I do something like this: if SPECIFIC_CLASS: from company.acctdb.specific import SpecificClass as BaseClass with the idea that at some point in the future I'd designate a different class in some other way? Hopefully this is enough info for you to see what I'm trying to accomplish. It's a bit like the DB interfaces, where there is a generic DB API, and then the different drivers to implement that API (MySQL, etc). Thanks for any suggestions! -scott -- http://mail.python.org/mailman/listinfo/python-list