Hi, On 20 March 2011 15:00, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton <jim@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.
I agree - this is nicer. In Grok's defence, class decorators didn't exist when martian was conceived. :) I do wonder whether it's nicer *though*, though, to justify yet more proliferation of configuration syntax. I appreciate that in Python 3 the in-class advice (which was pioneered by zope.component/zope.interface, don't forget) may not work properly, so we may not have any choice eventually. But saving two lines of code in a hypothetical example doesn't necessarily outweigh the confusion that comes from having multiple ways to do things, and grokcore.* configuration is in use in the wild outside of Grok. Martin