On 03/20/2011 03:28 PM, Jim Fulton wrote:
> Hm, it's been a while since I've looked at grok. Some notes:
We have more than four years of experience with this topic...
> - The mechanism I'm thinking of should not require *any* ZCML.
Check. we just bootstrap the grokking process from ZCML right now. We
use zope.configuration actions to be compatible with 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.
The basic principles are still the same. We still import code and grok
those classes/instances/functions we want to do something with.
Now that we have class decorators we could come up with another
collection mechanism however. That said, you'd still need to import the
modules at some point, otherwise collection will not take place as the
decorators don't get executed in the first place.
Martian has been expanded a lot though. I recommend looking at Martian.
> - I'd prefer not to rely on subclassing, but I'm not dead set against it.
Class decorators might work. Subclassing does have some nice properties
though; it feels Python and it becomes easy to come up with your own
domain specific base classes. But it's not a major gain over class
decorators I imagine.
Note that if you do directives on classes at all, you're going to have
to think about how subclassing interacts with configuration.
'implements' is a good example of that.
> - 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::
> 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.
Yeah, a nice project would be to let Grok use class decorators instead
of old style traceback-exploiting class directives. We have a fairly
well defined directive mechanism which knows about inheritance. It even
knows about module-level directives that affect all classes in the
module and then those classes have subclasses.
> 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.
I'm not sure how the behavior would be affected based on experience. For
'implements' for example, we still want subclassing behavior, don't we,
decorator or not.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -