On Wed, Apr 25, 2012 at 5:52 AM, Nick Coghlan
... tackle the problem of choosing between multiple implementations of a module at runtime ...
I like the idea, but I'm not sure I would like the result. The obvious path (at least for experimenting) is to replace the import statement with an import function. (a) At the interactive prompt, the function would return the module, and therefore allow it to be referenced as _. (I don't always remember the "as shortname" until I've already hit enter. And often all I really want is to see help(module), but without switching to another window.) (b) The functional interface could expose a configuration object, so that in addition to deciding between alternate implementations, a single implementation could set up objects differently. (Do I really need to define that type of handler? What loggers should I enable initially, even while setting up the rest of the logging machinery? OK, let me open that database connection before I define this class.) These are both features I have often wanted. But I don't want to deal with the resulting questions, like "Wait, how can that logger not exist? Oh, someone else imported logging first..." And I'm not sure it is possible to get the freedom of (b) without those problems, unless modules stop being singletons. -jJ