On 03/21/2011 03:07 PM, Lennart Regebro wrote: > On Mon, Mar 21, 2011 at 14:17, Martijn Faassen<faas...@startifact.com> wrote: >> Anyway, Grok's configuration is dependent on the rules you give it, so >> it's possible to have a completely explicit set of directives with no >> implicit fallback to default values whatsoever. Martian supports that >> scenario right now. > > Sure, but I'm of course referring to how it behaves by default, > including the associations made by the grokking process. > I think that makes sense in a webapp, but not otherwise, and we should > at least as a start concentrate on the generic component architecture > case. > >> For Martian, Python 3 support is mostly an issue of making class >> directives work as class decorators. > > And the same goes for zope.component support, of course.
We have a much more extensive directive abstraction though. That should make it harder and easier at the same time. :) > With martian, the registration is then done by the grokking process, > but I think decorators would be a process that is more acceptable to > the Python world in general. Instances does indeed require something > else than decorators, I hadn't thought of that, that's a drawback. Do we really care about "the Python world in general"? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. You'll still need a module importing process, as I sketched out elsewhere, if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Note that we do support function decorators with Martian. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )