On 3/29/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
Pro:

[...]

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

All of these con arguments go for bsddb, too, and without sounding too negative about bsddb, I believe SQLite is a *much* better solution than BerkeleyDB, for roughly the same problem space. The same goes for pysqlite vs. bsddb. IMNSHO, SQLite and pysqlite are much easier to use correctly than BerkelyDB and bsddb, for simple and complex tasks. I may be biased against bsddb because I spent too much time hunting refleaks in it, but I'm not biased in favour of SQLite -- I'm a PostgreSQL user myself. ;-P

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

Actually, I have no doubt that all the package managers will split the 'bundled' pysqlite (whatever the name will be) in a separate package, just like it's done for Tkinter and bsddb and most other stdlib modules with extra dependencies. Nevertheless, adding it to the standard library is probably a good thing. I would probably choose sqlite instead of shelve/anydbm/bsddb if it were part of the standard library, even though it's probably installed on all my machines anyway. I guess it's a psych thing.

As for people asking about deadlocks, well, I much rather explain about sqlite deadlocks than about BerkelyDB transactions.

--
Thomas Wouters <[EMAIL PROTECTED] >

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________
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

Reply via email to