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.