drsalists at gmail.com
Tue Nov 30 02:28:20 CET 2010
On Mon, Nov 29, 2010 at 1:00 AM, Antonio Cuni <anto.cuni at gmail.com> wrote:
> 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
> > due to licensing, but last I heard it'd become readily available), it's
> > to pretend it has ndbm using something else.
> > I'd call that puzzlingly worded - it's not the interface that's changing,
> > 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
> > skimmed that page so quickly ^_^
> > CPython 2.7's configure script has:
> > --with-dbmliborder=db1:db2:...
> > 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
> with cpython on ubuntu. There is still the issue of how to find the
> 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
> discussing here.
> To summarize, I think we should keep the current dbm.py to link against
> and integrate your gdbm.py to link against libgdbm. But before merging it
> trunk, I'd like to solve the issue of code duplication between the two
I should have time for this sometime this week or the next.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pypy-dev