[Python-Dev] SQLite module for Python 2.5 (original) (raw)

Paul Moore p.f.moore at gmail.com
Thu Oct 21 16:23:28 CEST 2004

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 unbundle 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.

More information about the Python-Dev mailing list