[Grok-dev] template association redux: module-level directives and inheritance

Brandon Craig Rhodes brandon at rhodesmill.org
Thu Sep 25 12:56:50 EDT 2008


Martijn Faassen <faassen at startifact.com> writes:

> Perhaps another fall-back level:
>
> 1) look for the directive on the class
>
> 2) look for the directive on the module
>
> 3) look for the directive on the module of the base class.

Ack.  That sounds complicated, hard to remember, and hard to debug.

The point of Grok directives is to put configuration information in our
code.  They should, therefore, always be easy to track down - the whole
point of putting it in code is to make it easier to find, and our
applications easier to read and write, than it was in the horrible old
days of ZCML, right? :-)

Let's think about this.

Python provides two kinds of "scoping".  If, on the one hand, I use a
bare variable name like "foo", then the "foo" to which I am referring
obeys the rules of lexical scoping: it will either be in the function
you're reading, or in an enclosing scope (the enclosing function, class,
or module) outside the function.  If, on the other hand, I use
"self.foo", then what I might call "object-oriented scoping" comes into
play, and I have a completely different direction in which to look for
where "foo" comes from: it might be defined either on this instance, or
its class, or any of its class's superclasses, or the metaclass on which
they are all based.

Searching for "self.foo" is, obviously, more difficult than searching
for "foo".  Lexical scoping is simpler than object-oriented scoping.

It sounds to me, faassen, like you are suggesting that things like
grok.template() or grok.templatedir() inherit in *both* directions, in
some order of preference.  I believe strongly that in this direction
madness lies.  It is hard enough to follow object-oriented scoping to
begin with; but to not know whether something is lexically scoped (like
module-level Grok directives are) or objectly-oriented-scoped (as an
inherited template location would be)?  We shall go mad, I tell you,
mad! :-)

Could we introduce a singleton named "inherit" in the Grok namespace
that directives recognize as "turning on" object-oriented inheritance?
If I had to maintain jw's code after he's done with it, and saw a class
that said something like:

    from BasicViews import SearchView

    class MoreSpecificSearchView(SearchView):
        grok.template(grok.inherit)
        ...

then I would know "Aha!  Instead of looking 'outward' through the outer
levels of lexical scoping for where this template (or templatedir, if
that is how I had done the example) comes form, I should look up its
chain of inheritance, like I do when looking for something that follows
"self." in a method."

And I would be happy.

Well.

At least, happier.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Grok-dev mailing list