Martin Maney wrote:
> On Wed, Apr 07, 2004 at 01:53:18PM -0400, Graham Fawcett wrote:
>
>>    _other_exports = {
>>        '$one': _dollar_one,
>>    }
>>
>>    _q_exports.extend(_other_exports.keys())
>>
>>    def _q_resolve(name):
>>        return _other_exports.get(name)
>
>
> At this point you're mucking with the list in order to save what, one
> function call during name resolution?  Or is there some other advantage
> over using _q_lookup in place of _q_resolve here?

No, I'm not at all concerned about performance. Motivations:

-- don't modify Publisher.

-- don't add any new classes, functions or _q_ words, which would hide
complexity that really should be visible. It is good that this stuff is
transparent. (Also, the _q_ vocabulary is quite small, and must stay
that way, IMHO, if Quixote is to feel natural and unobtrusive.)

-- move the "other" exports into a declarative structure, away from an
if..elif procedural style. This, to me, was the real winning point:
leave procedures to things that really need to be procedural. It looks
and acts more like _q_exports, and provides a nice summary at a glance.

-- place the "other" exports as close as possible in the source to the
_q_exports structure, and keep the names similar, for high readability.

-- use succinct code that's easily readable, and reproducible without
having to look something up. In other words, strive for an idiomatic
solution.


As for _q_lookup vs. _q_resolve: personally, I don't see any 'advantage'
of one over the other. I think it's a question of intent: _q_resolve
should be for lazily-bound, static things; _q_lookup should be for truly
dynamic (unbound) lookups.

If this doesn't concern you, there's no real reason not to use _q_lookup
instead, and avoid the _q_exports.extend() call: I imagine the
performance difference would be negligible, and you'd save a line of
code! ;-)

Best wishes,

-- Graham