[Python-3000] dbm package creation (original) (raw)
Guido van Rossum guido at python.org
Wed May 28 00:31:44 CEST 2008
- Previous message: [Python-3000] dbm package creation
- Next message: [Python-3000] Hello World!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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/)
- Previous message: [Python-3000] dbm package creation
- Next message: [Python-3000] Hello World!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]