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

[Hanno Schlichting]

On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton <jim at zope.com> wrote:
> - 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.

Both Grok and Pyramid (or martian and venusian really) do a scan of
the code to find the registration hints.

I think you cannot avoid this, if you want to support an explicit
configuration phase. Otherwise the first import of a module could
occur at any point at runtime and have a configuration side-effect
like registering a new view. Personally I find the venusian approach
pretty simple and explicit enough.

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

Taking one of the examples of grokcore.component, I think there's a
lot that can be made simpler:

import grokcore.component
from zope.i18n.interfaces import ITranslationDomain

class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
    grokcore.component.implements(ITranslationDomain)
    grokcore.component.name('helloworld')

Based on my Pyramid exposure, I'd write this as something like:

from something import utility
from zope.i18n.interfaces import ITranslationDomain

@utility(ITranslationDomain, name='helloworld')
class HelloWorldTranslationDomain(object):
    pass

This does mean hardcoding default values into the registration calls.
I'm not sure I see the value of avoiding this, as long as there's a
way to unregister this utility and re-register the class with other
values.

Hanno