I was really surprised when reading through the changes for the upcoming Python 2.5 release to discover that pysqlite will now be included in the standard library. If you aren't familiar with it, pysqlite provides an interface to SQLite which is an embedded SQL library. I use pysqlite all the time, so I found this really interesting.
Some immediate positive things I see about this:
- One less dependency that end-users have to care about.
- One less package to install on my development machines.
- Inclusion in the standard library (tends to) indicate that the code has been more rigorously reviewed for correctness and adherance to Python standards.
However, there is one negative side that affects all bundled modules that depend on external libraries: The bundled SQLite DLL won't necessarily track the latest official version. What I usually find in this sort of situation is that I have to choose to either keep the "stock" version on my development machine, or replace the stock version and track the latest version on my development machine. The first case has the advantage of remaining compatible with the stock Python, so users don't have to download extra dependencies. The second case has the advantage of letting you use newer features, but losing compatibility with the stock Python. Add to that the possibility of maintaining multiple code bases, each requiring a different version, and it's even worse.
There is an old (and apparently no longer maintained) document called The Whole Python FAQ that gives criteria for accepting a new module into the standard Python library. Paragraph 2.14 states (among other things):
2.14. When can a third-party module be added to the core python distribution? ... 4. Python releases are somewhat infrequent as compared to the update schedule for young modules. If the release frequency is too fast with respect to Python updates, then it is likely that the Python distribution will often be out-of-date. ... 6. Would inclusion unfairly discourage alternative approaches? For instance, the decision to bundle Tkinter with Python has made it more difficult for alternative GUIs to establish themselves.
Item 4 is what I'm talking about above, and the very likely possibility of the builtin SQLite falling behind the latest revisions of the SQLite library (it seems to be updated about once a month). However, item 6 is interesting as well.
When it comes to GUI libraries, wxPython is (IMO, of course) a far easier to use (and more Pythonic) library than Tkinter, but Tkinter is still hanging on because it is the bundled GUI for Python. A beginner Python programmer may well think that Tkinter is the "best of breed" just because it is included in the standard library, and never try the alternatives. Still other people would argue for PyGTK to be the standard GUI library. Perhaps one day a clear favorite will emerge, but until (if) that happens, I'd rather none of them be bundled. Bundling such a large package might encourage more modules to become "locked in" to the PyGTK (or wxPython) framework and lose portability.
In the case of SQLite, there is another wrapper called APSW that takes a more "hands-off" approach, and provides a thinner API. Many people might prefer this if they tried it, but once pysqlite is in the standard library, there will be less motivation to try the alternatives. Now, pysqlite has the advantage of being DB-API compatible, so that's a stronger argument for it versus APSW, but I think item 6 is still a valid criteria.
There is an article, "Thinking About the Python Standard Library", that discusses these same topics. One possible solution it mentions is to support versioning of Python libraries. I think it would be great if you could keep multiple versions of a library on the same machine, and select which to use at runtime. As a matter of fact, wxPython already does this. I wish this practice was standardized across more packages.
As a sidenote: PHP, which has always appeared to take a "bundle everything!" approach, has unbundled a couple of packages for PHP5 (MySQL and XSLT). I'm curious to see how PHP evolves in this respect now that PECL has come online. Will PHP and Python become more "core" oriented, and less bundle-happy, or will the opposite occur? It will be interesting to see what happens.
Update: Here is a description of how wxPython supports multiple concurrent installed versions.

Comments
Does Python have an easy to
Does Python have an easy to use module install tool, like Perl has the CPAN "shell" and Ruby has "gem"? That I think might help with the "lock-in" issue that you mentioned. pysqlite sounds like a nifty addition though.
distutils is pretty easy
distutils is pretty easy already, but there is something called PythonEggs that's supposed to be even easier, giving you dependecy checking, etc.
With "lock-in", though, I'm more talking about getting tied into a particular code framework. i.e. becoming tied to wxPython's event system, instead of writing more generic Python code. This post talks more about this (about halfway down, under "Frameworks cause some problems").
Post new comment