[Python-Dev] pysqlite for 2.5?

[Phillip J. Eby]

At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
>On 3/28/06, Anthony Baxter <anthony at interlink.com.au> wrote:
> > I'm happy to work with Gerhard to make this happen. Does it need a
> > PEP? I'd say "no", but only because things like ElementTree didn't,
> > either. Does it need a BDFL pronouncement? I'd say yes.
>
>Unless you've recanted on that already, let me point out that I've
>never seen sqlite, and I've ignored this thread, so I don't know what
>the disagreement is all about. Perhaps one person in favor and one
>person against could summarize the argument for me?

Pro:

* SQLite is really nice to have for writing simple applications with small 
data needs, especially client-side software.  It's probably the 
best-of-breed open source embedded SQL DB right now.

* So, having a wrapper would be a big "Batteries included" plus for Python

Con:

* Competing Python wrappers exist
* SQLite itself is updated frequently, let alone the wrappers
* Build integration risks unknown, possible delay of 2.5?
* Another external library to track and maybe have emergency updates of


I personally lean somewhat toward the con side because to me it's just as 
easy to "easy_install pysqlite" after the fact, or get it from the 
appropriate packager (RPM, Debian, whatever).

However, we can't please everybody.  If we go for more "batteries 
included", one group will complain about how much we have linked in and 
don't have proper system dependencies.  If we go for "easy to install 
add-ons", the same people will gripe that it's the job of the packaging 
system to do those add-ons, and another group will chime in that they don't 
have or don't want the packaging system.  So we might as well flip a coin.  :)