[Python-Dev] SQLite module for Python 2.5

[Paul Moore]

On Thu, 21 Oct 2004 11:41:30 +0200, Gerhard Haering <gh at ghaering.de> wrote:
> On Thu, Oct 21, 2004 at 11:26:12AM +0200, M.-A. Lemburg wrote:
> > Gerhard Haering wrote:
> > >My point is to include a usable DB-API 2.0 implementation that people
> > >can use as a starting point when developing applications that need a
> > >relational database. Other languages do the same btw. Java (win32?)
> > >includes a JDBC driver or ODBC, and PHP5 includes a SQLite module.
> > [...]
> > If you are just after a "usable database driver", then I have to
> > agree with Skip: any of the other available drivers would fit in
> > just as well. Please clarify this.
> 
> I'm aiming at a usable DB-API implementation in the stdlib that does
> not need a server. I want Python to have an RDBMS interface that works
> OOTB, no administration required. SQLite seems the obvious choice to
> me, haven't looked at Gadfly in a while, and MySQLdb/MySQL embedded
> (GPL) has licensing issues (and adds megabytes to the Python binary
> download, instead of ca. 270 kB uncompressed as for SQLite).

I'm +1 on including PySQLite in the core. It would fit in the same
space as Berkeley DB, *not* client-server databases like MySQL,
PostgreSQL, Oracle, etc. However, it conforms to 2 important
standards, SQL and the Python DB API, where Berkeley DB does not. This
matters where people are looking for a more "portable" solution
(whether that means scaling up to a full RDBMS at a later stage, or
scaling *down* from such a thing, for a more standalone application,
or just leveraging existing expertise).

I don't think that the issue of batteries included vs easier package
installation is relevant here - at the moment, Python *is* "batteries
included". While a better package management solution is a laudable
goal, until someone comes up and produces something, it doesn't affect
the situation - when such a thing exists, I would assume that it would
be appropriate to *un*bundle parts of the current stdlib (BSDDB, XML
come to mind as "big" areas). Having to also unbundle PySQLite again
shouldn't be too much of a chore. (If we're not willing to unbundle,
the message is that the packaging solution is good enough for others,
but not for "us" - a message I wouldn't feel happy supporting...)

Paul.