Re: Distutils confuses Berkeley DB and dbm?
Okay, after a little investigation (about 30 seconds staring at setup.py), I see where the problem with dbm is. Setup.py has this code to deal with dbm: # The standard Unix dbm module: if platform not in ['cygwin']: if (self.compiler.find_library_file(lib_dirs, 'ndbm')): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['ndbm'] ) ) elif self.compiler.find_library_file(lib_dirs, 'db1'): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['db1'] ) ) else: exts.append( Extension('dbm', ['dbmmodule.c']) ) That second branch is just plain wrong. (I realize Neil added it in response to a bug report.) While it's true that Berkeley DB does (or did) provide a dbm API, the underlying file is a db1 hash file, which we all should realize by now is horribly broken, and if you've got a workable bsddb there's no sense in trying to trick programmers into thinking they also have real dbm files. I suggest we discard the elif branch. Any argument? Skip
Okay, after a little investigation (about 30 seconds staring at setup.py), I see where the problem with dbm is. Setup.py has this code to deal with dbm:
# The standard Unix dbm module: if platform not in ['cygwin']: if (self.compiler.find_library_file(lib_dirs, 'ndbm')): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['ndbm'] ) ) elif self.compiler.find_library_file(lib_dirs, 'db1'): exts.append( Extension('dbm', ['dbmmodule.c'], libraries = ['db1'] ) ) else: exts.append( Extension('dbm', ['dbmmodule.c']) )
That second branch is just plain wrong. (I realize Neil added it in response to a bug report.) While it's true that Berkeley DB does (or did) provide a dbm API, the underlying file is a db1 hash file, which we all should realize by now is horribly broken, and if you've got a workable bsddb there's no sense in trying to trick programmers into thinking they also have real dbm files. I suggest we discard the elif branch. Any argument?
Sounds reasonable to me, but I'm no expert in this area. (I still have a pending bug report on why whichdb gets confused sometimes.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> Sounds reasonable to me, but I'm no expert in this area. (I Guido> still have a pending bug report on why whichdb gets confused Guido> sometimes.) I've been looking at that as well. Whichdb isn't actually very smart and has a schizophrenic relationship with its input "filename". It "knows" that certain types of db libraries build files with certain extensions and it knows the magic numbers of a few others. If you ask it what kind of file "foo" is, it first concatenates certain file extensions to see if it can tell if it's a dbm or dumbdbm file. The original dbm (and I think ndbm) C libraries created "foo.pag" and "foo.dir" when asked to create a "foo" file. When you use Berkeley DB's dbm-compatible API it still creates a Berkeley DB file underneath the covers, so the filename sniff tests that would return "dbm" will fail. So it's on to the next step. It then tries to simply open the filename as given. This will fail if you call whichdb.whichdb("foo") if "foo" was created by Berkeley DB, because the actual file is "foo.db": >>> import whichdb >>> whichdb.whichdb("foo") >>> whichdb.whichdb("foo.db") 'dbhash' So whichdb is broken. It tries to treat its argument as both a file prefix and a file name. I don't think you can have it both ways. Fixing it properly will require one or the other of these interpretations of its input argument to disappear. Skip
participants (2)
-
Guido van Rossum -
Skip Montanaro