Hi, On 20 March 2011 15:00, Hanno Schlichting <[email protected]> wrote: > On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton <[email protected]> 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 _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
