[Python-3000] dbm package creation

Guido van Rossum guido at python.org
Wed May 28 00:31:44 CEST 2008


On Tue, May 27, 2008 at 2:37 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
>
>>>>>> 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. :-)
>
> I just realized: since dumbdbm's "error" is just IOError, using
> "except [any]dbm.error" will always catch IOError.
>
> So the easy solution is to just derive the database error classes
> from IOError.
>
> The slightly harder solution is to declare the above a bug, create
> a new builtin (at least on C level) error class DBError and derive
> them from that.

I think deriving them all from IOError is good enough.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list