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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4