On Tue, May 27, 2008 at 2:37 PM, Georg Brandl <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
