[Python-3000] [Python-Dev] dbm.sqlite

[Raymond Hettinger]

>>> Given that the *API* is fixed though, it is probably better to have the
>>> module present in 3.0 and bring it back to the main line in 2.7.
>>>
>>> If any absolute clangers from a performance/stability point of view get
>>> past Raymond (and everyone else with an interest in this) then they can
>>> be addressed in 3.0.1 in a few months time.
>>
>> I agree about performance but I don't think it's right to say we can fix
>> stability later. This is a storage module, and people risk losing their data if
>> there are glaring bugs. If we really want an efficient dbm-compatible storage
>> backend for all platforms on 3.0, then why not bite the bullet and re-add bsddb?
>> Even though it has its quirks, it's certainly much more tested than a
>> hypothetical dbm.sqlite whipped up in a few days and used by nobody in the wild.
>
> Yes and no.  Sqlite in Python 3.0 has been tested and used more than
> bsddb in Python 3.0, this can be trivially seen because sqlite has
> been working in Python 3.0 for quite a while, which hasn't been the
> case with bsddb in Python 3.0.  While the wrapper for sqlite to offer
> a dbm-like interface is relatively untested (it does have testcases
> thanks to Skip), dealing with a couple-hundred (at most) line wrapper
> is far more reasonable for testing, verification, bugfixing, etc.,
> than the wrappers for bsddb.

I concur.  Sqlite is very stable, especially for our purposes here (records with only a text key paired with a pickled blob).  Also, 
the dbm API and mapping API's have been worked-out long ago.  Also, we've got the shelve test suite to exercise the setup.  And the 
wrapper module is small enough and simple enough to be very easier to review.  Doesn't get much easier than this.


Raymond