Guido van Rossum schrieb:
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?
No. The mapping is
dbhash -> dbm.bsd
dbm -> dbm.ndbm (*)
gdbm -> dbm.gnu (*)
dumbdbm -> dbm.dumb
(*) Not exactly; the original C modules are now called _dbm and _gdbm,
and the submodules are stubs that import those.
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.)
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
