[Python-3000] dbm package creation

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