[Python-3000] dbm package creation

Tue May 27 23:30:45 CEST 2008

On Tue, May 27, 2008 at 2:16 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> 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.

OK. I see. Hadn't remembered how messy it was. :-(
I withdraw my opposition to returning module names. I still think
returning a module would be a bad idea.
>>>> 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.)

OK, let's make the latter a stretch goal. :-)
-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)