On Thu, 21 Oct 2004 11:41:30 +0200, Gerhard Haering firstname.lastname@example.org 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...)