On Mon, Nov 29, 2010 at 1:00 AM, Antonio Cuni <[email protected]> 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 > 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: > > > > --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 > 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 > discussing here. > > 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. > > ciao, > Anto > Agreed. I should have time for this sometime this week or the next.
_______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
