[PYTHON DB-SIG] database API

[Greg Stein]

>----------
>From: 	Thomas Breuel[SMTP:tmb@best.com]
>Sent: 	Saturday, October 12, 1996 11:36 PM
>To: 	Greg Stein; 'Thomas Breuel'
>Cc: 	'db-sig@python.org'
>Subject: 	RE: [PYTHON DB-SIG] database API
>
>That's fine, but not quite what I'm trying to get at.  The main
>distinction I think is missing from PyDB is that between a Connection,
>a PreparedStatement, and a ResultSet/Cursor.  Recognizing that you
>are reexecuting a query with what happens to be the same string just
>does not seem right to me, and, in any case, differs substantially from
>the approach taken by database APIs in other languages.

I fully agree that it is not obvious. :-(

While a definite shortcoming, it hasn't ever bothered me enough... :-)

>I'm approaching this first of all as a "consumer": under what
>conditions can I choose Python/PyDB over an equivalent Perl/DBI or Tcl
>solution.  Python already will be less familiar to our potential users,
>so any deviation of PyDB from more familar APIs like ODBC or JDBC is an
>additional negative.  My technical preference for Python as a language
>is only one of a number of factors.  I suspect that my concerns are
>fairly typical for people considering doing database work in Python.

Could be. Unfortunately, I haven't spent the time to get the darn spec
more widely published (outside of this sig) and modules implementing it
were not freely available (outside of eShop :-) until only very
recently. In other words... it is only until very recently that people
have had a chance to work with the current spec.

If you're still choosing your language... well... hrm. :-)  Like I said,
I think the API speak more to people who may have chosen Python already.
Nevertheless, with your input, changes could help to broaden Python's
database appeal.

However, I'll also point out that, at least as far as this sig goes,
people have had very little comments for change. Whether from it being
correct, or people just being quiet, I have no idea :-)

>In any case, I'll give it more thought and maybe send out a spec, and
>possibly a wrapper around existing code, that might form a more
>concrete basis for a discussion.  But that makes only sense if there is
>some willingness to talk about such changes to PyDB.  I have no
>interest in setting up a competing standard; if I should feel (I
>haven't made up my mind yet) that the current PyDB API is so different
>from what our user community expects that that was necessary and that
>it couldn't be changed, I'd simply go with another solution rather than
>fight over this.

As I mentioned, people haven't had much exposure to the current spec, so
actual input would be welcome (as far as I'm concerned).

I'll throw in one caveat to this whole thing, though: I'm not involved
with the coding of database modules anymore for Python. My
needs/interests have diverged since I first started applying thought and
time to Python's database interfaces. Changes to existing modules and
developing new ones would need to be done by others. I'll gladly
contribute talk and viewpoints and whatnot, but coding is a different
story.

Heh. And a note my philosophy book: he who codes it, wins the spec
argument over he who does not. :-)

Cheers,
-g


=================
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
=================