On 07 December 2002, Martin Maney said: > I'm not entirely certain I grok this in fullness, since whatever it is > doing is, patently, something I'm not using. But if I'm not completely > at sea, the objective is to tweak performance through lazy loading of > modules. yes? No, Quixote already does lazy importing. Look in Publisher.get_component(), where it says "Third security check". If I understand Jon correctly, he wants to override the code that guesses the name of the module to import -- Quixote's guesswork is, IMHO, correct for most situations, but it's certainly possible to craft your applications such that Quixote guesses wrong. For example, say your root namespace is 'myapp'. Then the URL "/foo/" would be handled by the 'myapp.foo' namespace, presumably a module. It's entirely possible that myapp/__init__.py does this: from some.other.package import foo or even from some.other.package import blah as foo in which case simply importing 'myapp.foo' will not work -- and that's what Quixote attempts to do when it sees that the 'myapp' namespace has no 'foo' attribute (and 'foo' is exported from 'myapp'). Jon, is that what's going on in your case? Or is it more subtle? > Then I would think it might better be named something > evocative of that. I may be unduly influenced by recent conversations > elsewhere, but this sounds like it might be a _q_bind_name kind of a > thing. The trouble with that name is it's what we *should* have used for _q_getname() -- *sigh*. I'm not thrilled with the name _q_import(), but I can't think of anything better. And now that I've written up the above explanation, I can finally see why Jon wants it, so I'm willing to add it. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange http://www.mems-exchange.org