[DB-SIG] interogating C langauge drivers

James Northrup james_northrup@iridium.com
Wed, 17 Mar 1999 17:59:28 -0500

Greg Stein wrote:

> James Northrup wrote:
> >
> > > Hmm. We could try getting the DB API specification into the standard
> > > docs for Python. That would add a little more "official" flavor to
> > > our work.
> >
> > questions regarding this sig:
> >
> > 1) Is there an issue in publishing a module of abstract classes to adhere to ?
> The DB modules aren't going to be able to subclass from them since the
> modules must be implemented in C. Therefore, publishing something like
> this doesn't really provide any more information than the specification
> that we currently have.

The specification that we currently have tells me nothing about xyz module that I download in the hopes of interfacing my dbms.  It just prescribes doctrine.  Without a
common parent or wrapper or factory interface or some sort of abstract object, using more than a single db-api module is to double check each step so that one can be assured
a generalized interface can be used in core application functionality without rewrite or tuning.  and if the check fails? you absolutely will do rewrite and tuning.

this is bad practice, regardless of flexibility or constraints of a C-written python module.

C is a systems development language.  It works well for systems drivers.  this db-sig seems to speak of driver specification of various C modules that cannot be subclasses.
I am trying address the full application maintenance standpoint of having benefit from this C driver convention.

I contest the futility of an abstraction higher than raw calls.

python is an application development language.  we should not have to suffer for the sins of binary libraries.

> > 2) Why stop at the docs for python if we can publish self documented base classes as well?
> > I have looked frantically for a dbapi.py and all I have found are disparate c modules that don't have parent class interfaces.
> > If such an animal exists, I would love a pointer.  I would gladly step out of this discussion and into one about improving such a module.
> There is no such beast. The C modules can't have a parent class
> interface (without undue strain, and with little benefit). This is
> simply the way Python works.

I re-iterate, for the undertaking of strain and little benefit, I dare to tread out of here and into something constructive that lends a stronger application side interface.

> > 3) Java has a comfortable "Interface/Impl" flavor of libraries, why is the db-api an ethereal specification of convention rather than an entry point in code interface?
> Goody for Java.
> Python doesn't have strict interface mechanisms, so that programming
> methodology does not apply. Publishing a specification for people to
> conform to seems to work. There are people that do not conform to the
> spec; however, have a base class would not improve the situation... they
> just wouldn't use it if they didn't want to conform.

As I have tussled about in this sig it occurs to me none have yet spoken from the standpoint of building a kernel or drivers for n*m devices.  Everyone wants to write a
driver that conforms, only does it better than the spec.  So many creative endeavors.

As time permits, I shall build a pure python module that performs the task of interrogating modules (or driver, hereafter).

These drivers it interrogates will belong to a registry.  The user will "register" drivers at runtime.

The interrogation results shall provide a driver-capability model for each subject driver.

These driver capabilities shall be fashioned directly after the [DB-SIG] annotated 1.1 spec. (initially)

As this undertaking nears completion, I will gladly offer this small bit of purpose-written abstraction into a larger base of usage and support.