[Python-Dev] SQLite module for Python 2.5

Ian Bicking ianb at colorstudy.com
Thu Oct 21 09:42:19 CEST 2004

Skip Montanaro wrote:
> It seems people misunderstood my comment.  I should have been more clear.  I
> see no reason PySQLite should be accorded better status than any of the
> other relational database wrappers.  If MySQLdb, etc aren't included with
> the distribution I don't think PySQLite should be either.  I realize it's
> easier to administer a PySQLite database than a PostgreSQL database, but
> from a pure client standpoint there's nothing really easier about it.  By
> including PySQLite we'd somehow be blessing it as a better SQL solution than
> the other options.  That means it will almost certainly be stretched beyond
> its limits and used in situations where it isn't appropriate (multiple
> writers, writers that hold the database for a long time, etc).  That will
> reflect badly on both SQLite and Python.

While I like the idea of SQLite wrappers in the standard library, I 
think this is a good point -- and indeed, a lot of people run up against 
the limits of SQLite at some point (e.g. PyPI).  I think SQLite is a 
good transitional database, and as such it will often be a sufficient 
long-term choice, but for a lot of applications it will ultimately be 
too limiting.

I am particularly concerned if the SQLite bindings become less like the 
other DB-API bindings, so that it is hard to port applications away from 
SQLite.  Specifically, while the type coercion isn't perfect, it makes 
SQLite *much* more like other RDBMS's; I'd be bothered if by default 
SQLite acted significantly different than other databases.  While the 
DB-API doesn't address this issue of return types, it's only an issue 
for SQLite, since all the other databases are typed.

Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org

More information about the Python-Dev mailing list