M.-A. Lemburg wrote:
[...] Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ?
- SQLite sources are 1.57 MiB uncompressed, we wouldn't want to add that to the Python sources download size, would we? - I personally would not want to have the job to "bless" a certain version of SQLite for being bugfree enough to be used until the next Python minor release. And we wouldn't want to push a Python minor release just somebody found an obscure data corroption bug in a SQLite release - SQLite might not compile on some less common platforms (AIX, HP/UX, Win64, whatever) that Python compiles fine on. - I believe Python is written in more portable C than SQLite. So it might be certain compilers that fail for compiling SQLite. - At some point you might also want a sqlite commandline shell instead of just the shared library, too. All of these are non-issues if we just compile against an installed SQLite on Unix-like system if it can be found. On Windows, I also prefer to have a dynamically linked SQLite Python module. We can distribute the SQLITE3.DLL with Python, and then people could just download an updated SQLITE.DLL from http://sqlite.org/ and overwrite the existing one of the Python installation, *if* an important bug is fixed in SQLite.
Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ?
This, and that you can prototype without having to install and configure a database server. For many applications, the prototype can be the final version. -- Gerhard