[Python-Dev] BSDDB3

Gregory P. Smith greg at krypto.org
Wed Apr 23 22:17:19 CEST 2008

On Tue, Apr 22, 2008 at 8:09 PM, Jesus Cea <jcea at argo.es> wrote:

> Hash: SHA1
> Trent Nelson wrote:
> | I remember those rampant BSDDB crashes on Windows well.
> [...]
> | basically, the tests weren't cleaning up their environment in
> | the right order, so BSDDB was getting passed completely and
> | utterly bogus values.
> Next week I will (if nothing goes wrong) publish pybsddb 4.6.4. This
> release supports distributed transactions and replication, testsuite is
> way faster, and rewritten to be able to launch tests from multiple
> threads/processes if you wish, setuptools/pypi support, etc.
> I think this release would be appropiate to integrate in Python. I think
> most demands are solved and new features are interesting (replication,
> distributed transactions, do not crash when closing objects in the wrong
> order...). Also, I completed the documentation, with the full supported
> API, and ported it to Python 2.6 documentation system. The result:
> http://www.jcea.es/programacion/pybsddb.htm#bsddb3-4.6.4
> http://www.jcea.es/programacion/pybsddb_doc/preview/
> I'm very interested in integrating this release in Python 2.6 for the
> new features, the full documentation, and to get feedback from Buildbot
> and python-dev community. Also, I would like to avoid to integrate
> pybsddb late in the python 2.6 release cycle; I hope to be away of my
> computer in August! :).
> I'm a bit nervous about syncing, because I have the feeling that
> python-dev is committing changes to python private branch of pybsddb. I
> would rather prefer patches send to me and integrate "canonical" pybsddb
> releases in Python frequently.
> Somebody suggested to post patches in the tracker, but I think this is
> not going to work. The diff from current python bsddb and the official
> version is so huge that nobody could follow it. A more sensible
> approach, I think, is to "diff" current python pybsddb against the
> version I used as my root (January?), integrate the changes in current
> "canonical" pybsddb and, then, drop the entire updated package into
> python.

Agreed.  I "forked" jcea's version found in his svn repository from python
trunk at r60209.

The only change to any Modules/*bsddb*  files made to python trunk since
then was me manually applying one bugfix that jcea had made in his
repository.  My goal all along had been to merge his changes back into
python trunk until he had commit access.  Obviously I haven't had time to do

The changes to Lib/bsddb/* since then have been test suite updates which I
think jcea should go through and selectively merge as appropriate into his
repository (he has done a lot of test suite cleanup). ( svn://
svn.argo.es/jcea/pybsddb/trunk )

After that, merging his changes into trunk will be relatively easy and I
think we should give jcea commit access and let him do it and henceforth use
python svn as the official repository for the pybsddb code and

I do not see this as a daunting task assuming jcea is willing to be
volunteered to do the merge and to handle any py3k merge issues that come

Alternatively: (removal of bsddb from the standard library)

If people want to go the other route a remove bsddb from Python all together
letting it thrive as a standalone addon module, what will this mean to the
old shelve and dbhash standard library that use bsddb?  Someone should write
a sqlite backend for shelve.  Either way it should not be removed from 2.6
as it needs to be marked at deprecated for one release round only to be
taken out in 2.7 and that does leave open the question of should it exist in
3.0 at all or just start out deprecated there?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080423/709002de/attachment.htm>

More information about the Python-Dev mailing list