[Python-Dev] pysqlite for 2.5?

Gerhard Häring gh at ghaering.de
Wed Mar 29 23:17:40 CEST 2006

Hash: SHA1

Phillip J. Eby wrote:
> At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
>> [...] Perhaps one person in favor and one
>> person against could summarize the argument for me?
> Pro:
> * SQLite is really nice to have for writing simple applications with small 
> data needs, especially client-side software.  It's probably the 
> best-of-breed open source embedded SQL DB right now.
> * So, having a wrapper would be a big "Batteries included" plus for Python

That would be my arguments, too.

> Con:
> * Competing Python wrappers exist

There is really only one other relevant wrapper: APSW. It was
purposefully designed to *not* use the DB-API 2.0 (though a similar
one), and being a "thinner" wrapper of SQLite.

It wraps a few more functions of the SQLite API, though less and less,
because pysqlite is catching up here.

While there might be arguments for a "thinner" wrapper, I think that
pysqlite has the advantage of being DB-API compliant (even with most
optional DB-API extensions) and thus offers a good way to prototype
database apps with a smooth upgrade path to other, more powerful, databases.

> * SQLite itself is updated frequently, let alone the wrappers

SQLite being updated regularly is not really a problem, because we can
link dynamically against SQLite. And we probably *should* do this on
Windows, too, so users can replace a SQLite.DLL with an updated version
if they wish to.

> * Build integration risks unknown, possible delay of 2.5?
> * Another external library to track and maybe have emergency updates of

Emergency updates are only for security problems, right? I don't think
this would apply to pysqlite. I don't think that would apply to SQLite
either, but if it's conceivable, it's another argument for dynamic linking.

- -- Gerhard
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the Python-Dev mailing list