S
Scott Sharkey
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
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