[Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

[Jan-Wijbrand Kolman]

Hi,

Not sure where to 'hook into' the discussion thread, so I'll just start 
here:

On 3/20/11 15:28 PM, Jim Fulton wrote:
> Hm, it's been a while since I've looked at grok. Some notes:
>
> - The mechanism I'm thinking of should not require *any* ZCML.

Do you mean "without having a configure.zcml trigger the scanning 
(a.k.a. grokking) process"? Or do you mean, "a mechanism that doesn't 
use configuration actions from zope.configuration"?

If there's a different way to trigger the scanning process, that would 
be mostly fine for Grok. There's a couple of things actually configured 
thru ZCML files in some of the grokcore.* packages. I think they could 
be rewritten if necessary.

ZCML files are as far as I can see not essential to Grok - they are 
surely not essential to martian (the scanning/grokking library used).

> - The mechanism shouldn't require something to "grok"/analyze the
>    code.  The mechanism should be explicit. This is implied by
>    "pythonic".  I remember Grok being more implicit than skimming the
>    links above suggest. Perhaps Grok has has become more explicit than
>    I remember.

I have the feeling the "explicit versus implicit" part of the discussion 
has been somewhat mixed with the "to scan or not to scan" part of the 
discussion.

Nothing in the martian library dictates "implicitness" as far as I can 
see. How Grok uses martian though, does have implicit, 
conventions-over-configuration design choices.

Actually, these "conventions-over-configuration" choices are regularly 
discussed within the Grok community - some people (including myself) 
would like to see Grok not doing any "guessing" of configuration 
parameters during the grokking-phase of the application at all. Others 
disagree.

As an example, there's the "megrok.strictrequire" package that, when 
included in a grok-based application, will raise grok errors when there 
are view components without an explicitly set permission requirement 
(where Grok normally would have used a conventional value).

> - I'd prefer not to rely on subclassing, but I'm not dead set against it.

For most components Grok relies on subclassing indeed. Note that 
registering global utilities, for example, can be done using 
module-level directives too, like can be done for adapters and 
subscriptions.

> - Whataever we come up with has to work with Python 3, so
>    unfortunately, we can't use the syntactic trick of having a call in a
>    class like::
>
>      grokcore.component.implements(IContentProvider)

Just to be sure: this is what is called "advice based syntax" or 
"in-class advice" right? Grok people call this a "directive".

Anyway, as apparently this wouldn't work in Python 3 anymore, Grok 
should come up with an alternate spelling. Actually, people have already 
suggested to start using class decorators instead of in-class 
directives. Personally, I do not see an essential cosmetic difference 
between using a class decorator or a in-class directive.

Like was said earlier in the thread: Grok had to use directives since 
there were no class decorators at that time.

And what I have seen of Pyramid and venusian, the grok directives do 
mostly what the class decorators do: they leave information on the class 
in one way or another, that later is picked up in the scanning/grokking 
phase and used for registrations.

Grok uses "grokkers" for that - "meta"-components that know how they can 
use the information left by the directives for making registrations 
(thru the zope.configuration configuration actions mechanism, which as a 
result plays nice with existing "pure zcml" registrations)

What I know of venusian/Pyramid, is that the class decorators leave 
callbacks that will do the registrations in the scanning phase. Right?

> The effort should certainly include an analysis of approaches like
> grok.  Maybe the mechanism should have the effect of enabling tools
> like grok to be implemented more cleanly.

I do not think the Grok project would be principally against this.

regards, jw