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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
