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
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