[Python-Dev] pysqlite for 2.5?
Phillip J. Eby
pje at telecommunity.com
Wed Mar 29 21:53:40 CEST 2006
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. :)
More information about the Python-Dev
mailing list