durusmail: quixote-users: [patch] _q_import
[patch] _q_import
[patch] _q_import
2002-12-02
2002-12-03
2002-12-03
2002-12-04
2002-12-07
2002-12-07
2002-12-09
2002-12-09
2002-12-05
[patch] _q_import
Greg Ward
2002-12-09
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

reply