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

Guido van Rossum guido at python.org
Tue May 27 22:59:10 CEST 2008

On Tue, May 27, 2008 at 1:48 PM, Georg Brandl <g.brandl at gmx.net> wrote:

Guido van Rossum schrieb:

On Sun, May 25, 2008 at 3:08 PM, Brett Cannon <brett at python.org> wrote:

On Sun, May 25, 2008 at 12:21 PM, Georg Brandl <g.brandl at gmx.net> wrote:

Hi, I'll handle the PEP 3108 dbm package if nobody else is already at it.

I know I have not started the work. Two questions though: * the whichdb() function returns strings that are module names. These names won't be importable anymore in 3k. Should the return values remain the same in 3k, or should whichdb() return the new names, and if the latter, including "dbm." or not? New names with the package name prepended. Should probably change the API at some point to just return the module to use instead of the name. 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?

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?

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list