[Python-3000] dbm package creation (original) (raw)

Georg Brandl g.brandl at gmx.net
Tue May 27 23:16:53 CEST 2008

Guido van Rossum schrieb:

I'm not sure I disagree. I see the return value as an enum, only one use for which is to import it. (If you wanted to just use the module, why not use anydbm?) I'd prefer to keep the return strings the same (no 'dbm.' prefix) and fix the code that uses whichdb.

So add a mapping to dbm.init that maps old names to new names? Is the mapping not just 'dbm.' + x?

No. The mapping is

dbhash -> dbm.bsd dbm -> dbm.ndbm () gdbm -> dbm.gnu () dumbdbm -> dbm.dumb

(*) Not exactly; the original C modules are now called _dbm and _gdbm, and the submodules are stubs that import those.

Or is there an expected future use case where the returned value would be something in a different package?

There was in the past, with the now-defunct bsddb185 module which was not used by anydbm.

Returning a module object would seem the least attractive version -- that would require importing the module, which may not be in the caller's plan at all. It may not be, but the modules are imported anyway during import of dbm.init (which contains whichdb() now.) Hm, that's a regression if you ask me. Couldn't you use lazy import?

There's a module attribute "error" -- supposed to be a tuple of all possible errors from the db modules; that is hard to make lazy.

Of course we could solve this by making all the different db module errors subclasses of a common exception (but since most of them are defined in C modules, this is hard again.)

Georg

More information about the Python-3000 mailing list