[pypy-dev] gdbm

Dan Stromberg drsalists at gmail.com
Sat Nov 27 01:18:29 CET 2010


On Fri, Nov 26, 2010 at 3:12 PM, Antonio Cuni <anto.cuni at gmail.com> wrote:

> On 16/11/10 04:30, Dan Stromberg wrote:
>
>  BTW, it might cause confusion down the road to call something that is
>> basically like cpython's bsddb (Berkeley DB) by the name "dbm" in pypy's
>> library.  In the cpython standard library, "dbm" is an interface to ndbm
>> databases.  These all provide the same dictionary-like interface to Python
>> programs, but have somewhat different API's to C, and pretty different,
>> incompatible on-disk representations.
>>
>
> Hi Dan,
> I played a bit (veeeery quickly) with dbm on both pypy and cpython, and I'm
> not sure I get what you mean when you say that our dbm.py is equivalent to
> cpython's bsddb. E.g., I can create a db on cpython and open it from pypy,
> so it seems that the two modules are compatible.
>
> Moreover, I checked which libraries the links to. On CPython, it links to
> libdb-4.8.so:
>
> viper2 ~ $ ldd /usr/lib/python2.6/lib-dynload/dbm.so
>        linux-gate.so.1 =>  (0x00884000)
>        libdb-4.8.so => /usr/lib/libdb-4.8.so (0x00110000)
>        libpthread.so.0 => /lib/libpthread.so.0 (0x003de000)
>        libc.so.6 => /lib/libc.so.6 (0x003f8000)
>        /lib/ld-linux.so.2 (0x002e0000)
>
> the pypy version first tries to open libdb.so, then libdb-4.5.so. I had to
> manually modify it to open version 4.8 (I agree that we should find a more
> general way to find it), but apart from that what I can see is that it uses
> the same underlying wrapper as CPython.
>
> So, to summarise: could you elaborate a bit more why we should delete
> dbm.py from pypy?
>
> ciao,
> Anto
>


Looks like dbm at the API level: CPython dbm, pypy dbm
Looks like dbm on disk: CPython dbm
Looks like bsddb at the API level: CPython bsddb
Looks like bsddb on disk: CPython bsddb, pypy dbm

Don't let the common prefix fool you - libdb is Berkeley DB, while dbm is
supposed to be ndbm.

http://docs.python.org/library/dbm.html

That is, pypy's dbm.py is perfectly self-consistent (other than a couple of
likely memory leaks), but if you try to open a database from CPython using
pypy's dbm module (or vice-versa), I don't believe it'll work.  EG:

$ /usr/local/cpython-2.7/bin/python
Python 2.7 (r27:82500, Aug  2 2010, 19:15:05)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import dbm
>>> d = dbm.open('d', 'n')
>>> d['a'] = 'b'
>>> d.close()
>>>
benchbox-dstromberg:/tmp/dbm-test i686-pc-linux-gnu 30890 - above cmd done
2010 Fri Nov 26 04:14 PM

$ /usr/local/pypy-1.4/bin/pypy
Python 2.5.2 (79529, Nov 25 2010, 20:40:03)
[PyPy 1.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``casuality violations and
flying''
>>>> import dbm
>>>> d = dbm.open('d', 'r')
Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/usr/local/pypy-1.4/lib_pypy/dbm.py", line 172, in open
    raise error("Could not open file %s.db" % filename)
error: Could not open file d.db
>>>>

HTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20101126/f2cc569e/attachment.html>


More information about the Pypy-dev mailing list