[Python-3000] dbm package creation

[Guido van Rossum]

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/)