On Tue, May 27, 2008 at 2:16 PM, Georg Brandl <[EMAIL PROTECTED]> wrote: > 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.
OK. I see. Hadn't remembered how messy it was. :-( I withdraw my opposition to returning module names. I still think returning a module would be a bad idea. >>>> 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. :-) -- --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
