[Python-3000] dbm package creation

[Guido van Rossum]

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