On 13 March 2003, Andrew Kuchling said:
> It would be two lines of code for backward compatibility, if we
> changed this.  I'm +0 on changing _q_getname to _q_lookup.
>
> If we're changing names, remember that:
>  _q_getname is called for names not in _q_exports, and isn't memoized.
>  _q_resolve is called for names     in _q_exports, and is    memoized.

That clarifies things nicely, thanks!  I think it even makes it clear
why we didn't munge the _q_resolve() functionality into _q_getname().

> Can we pick names that make this distinction slightly clearer?

I think the names are fine, assuming _q_getname() is changed to
_q_lookup().  ;-)  Here's my thinking: if I want to make URLs like
/user/joe or /process/XYZ-B-0013/edit work, I'm using part of the URL to
lookup some object from my database.  Hence, _q_lookup().  But if I have
a name in Python-space that isn't discoverable via Quixote's usual rules
(import and getattr subject to the constraints of _q_exports and
_q_access()), then I need to provide an alternate way to resolve
that name -- hence, _q_resolve().  Maybe I'm splitting semantic hairs
here, but the distinction is clear to me and I like those two names.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org