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 _______________________________________________ pypy-dev@codespeak.net http://codespeak.net/mailman/listinfo/pypy-dev
