[Python-3000] dbm package creation

[Georg Brandl]

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