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

[Martijn Faassen]

Hi,

On 03/20/2011 03:28 PM, Jim Fulton wrote:

> Hm, it's been a while since I've looked at grok. Some notes:

We have more than four years of experience with this topic...

> - The mechanism I'm thinking of should not require *any* ZCML.

Check. we just bootstrap the grokking process from ZCML right now. We 
use zope.configuration actions to be compatible with ZCML.

> - 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.

The basic principles are still the same. We still import code and grok 
those classes/instances/functions we want to do something with.

Now that we have class decorators we could come up with another 
collection mechanism however. That said, you'd still need to import the 
modules at some point, otherwise collection will not take place as the 
decorators don't get executed in the first place.

Martian has been expanded a lot though. I recommend looking at Martian.

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

Class decorators might work. Subclassing does have some nice properties 
though; it feels Python and it becomes easy to come up with your own 
domain specific base classes. But it's not a major gain over class 
decorators I imagine.

Note that if you do directives on classes at all, you're going to have 
to think about how subclassing interacts with configuration. 
'implements' is a good example of that.

> - 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)
>
> 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.

Yeah, a nice project would be to let Grok use class decorators instead 
of old style traceback-exploiting class directives. We have a fairly 
well defined directive mechanism which knows about inheritance. It even 
knows about module-level directives that affect all classes in the 
module and then those classes have subclasses.

> Note that the move from "advice-based" syntax to class decorators
> provides a good opportunity to revisit how some of this works based
> on experience using the ztk.

I'm not sure how the behavior would be affected based on experience. For 
'implements' for example, we still want subclassing behavior, don't we, 
decorator or not.

Regards,

Martijn