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.
Georg
_______________________________________________
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
