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

[Jim Fulton]

On Sun, Mar 20, 2011 at 9:49 AM, Martin Aspeli <optilude+lists at gmail.com> wrote:
> On 20 March 2011 13:46, Jim Fulton <jim at zope.com> wrote:
>
>> I think we ought to come up with a much cleaner way of defining
>> default configuration. (Pyramid does this by passing default values in
>> adapter calls, but I think we can do a lot better than that.)  I'd
>> like to see us come up with a "pythonic" way to wire components up
>> that can be overridden through registration (through zcml or
>> otherwise).  Ideally, the mechanism shouldn't "feel" like
>> "configuration" but like "programming".
>
> You mean like
>
> http://pypi.python.org/pypi/grokcore.component
> http://pypi.python.org/pypi/grokcore.view
> http://pypi.python.org/pypi/grokcore.viewlet
> http://pypi.python.org/pypi/grokcore.security
>
> ?

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

- The mechanism I'm thinking of should not require *any* 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.

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

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

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.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton