At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote: >On 3/28/06, Anthony Baxter <[EMAIL PROTECTED]> 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. :) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
