[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