anto.cuni at gmail.com
Mon Nov 29 10:00:09 CET 2010
On 27/11/10 04:07, Dan Stromberg wrote:
> This module can be used with the “classic” ndbm interface, the BSD DB
> compatibility interface, or the GNU GDBM compatibility interface. On Unix, the
> *configure* script will attempt to locate the appropriate header file to
> simplify building this module.
> I suppose that means that if it can't find ndbm (which at one time was hard
> due to licensing, but last I heard it'd become readily available), it's free
> to pretend it has ndbm using something else.
> I'd call that puzzlingly worded - it's not the interface that's changing, but
> the backend implementation. But perhaps dbm.py is free to use Berkeley DB if
> it prefers to pretend it can never find ndbm. And perhaps I shouldn't have
> skimmed that page so quickly ^_^
> CPython 2.7's configure script has:
> order to check db backends for dbm. Valid value is a
> colon separated string with the backend names
> `ndbm', `gdbm' and `bdb'.
so, having a dbm.py which links to libdb is fine, and it's also what you get
with cpython on ubuntu. There is still the issue of how to find the correct
library name, as it seems it can vary (it was db-4.5 when the module was
written, it's db-4.8 nowadays), but this is a bit orthogonal to what we are
To summarize, I think we should keep the current dbm.py to link against libdb,
and integrate your gdbm.py to link against libgdbm. But before merging it to
trunk, I'd like to solve the issue of code duplication between the two modules.
More information about the Pypy-dev