Re: Anyone want to do Google Summer of code mentoring for PSF?

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 )