[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

Josiah Carlson josiah.carlson at gmail.com
Thu Sep 4 20:54:58 CEST 2008


On Thu, Sep 4, 2008 at 10:03 AM,  <skip at pobox.com> wrote:
>
>    > Compared to sqlite, you don't need to know SQL, you can finetuning
>    > (for example, using ACI instead of ACID, deciding store by store), and
>    > you can do replication and distributed transactions (useful, for
>    > example, if your storage is bigger than a single machine capacity,
>    > like my case). If you combine Berkeley DB with Durus, for example, all
>    > of this is abstracted and you simply use "regular" python objects.
>
>    Titus> I agree.  I like bsddb for just this reason and I'd like to
>    Titus> continue being able to use it!  I think that there are many
>    Titus> reasons why having such a thing in the stdlib is really useful
>    Titus> and I also think it's worth exploring the ramifications of taking
>    Titus> it out...
>
> I suggested in another message (perhaps on another thread) that maybe a
> dbm.sqlite module would be worth having.  It would have a dict-ish API like
> the other dict-on-disk modules but use the sqlite module to read (SELECT)
> and write (INSERT and UPDATE) key/value pairs from the underlying database.

I offered to write one of these a couple months ago as an option for
some users who would otherwise think to use bsddb, dbm, or anydbm.
Few people saw that anything like that would be useful, detractors
stating that the expansive options available in bsddb (most of which I
didn't realize existed) made it effectively irreplaceable to the vast
majority of people who actually use bsddb for anything nontrivial.

There wasn't even feigned interest in those use-cases involving
"trivial" disk-persistent dictionaries (of which 100% of my uses have
involved over the last 10 years).

 - Josiah


More information about the Python-Dev mailing list