[Grok-dev] Re: five.grok
gotcha at bubblenet.be
Fri Aug 1 12:12:44 EDT 2008
Martijn Faassen wrote:
> Godefroid Chapelle wrote:
>> I am a bit skeptical about importing everything from grok.
>> I think it is better to see what is coming from where !
> As the developers of Grok we care quite a bit of what goes into that
> 'grok' namespace. We're separating packages out so they can be used
> independently if you don't want to use the whole of Grok. I think though
> "five.grok" has at is aim to establish as much as possible of the Grok
> API in Zope 2, so it's a shame we cannot then encourage people to use
> this API...
>> However, I understand others might like to use "from five import grok"
> What is your opinion about straight (non-Zope 2) Grok? Would you prefer
> that people write this:
> from grokcore.component import Adapter
> from grokcore.view import View
> class Foo(Adapter):
> class Bar(View):
> so that people can see "what is coming from where"?
> instead of:
> import grok
> class Foo(grok.Adapter):
> class Bar(grok.View):
> If so, why? We try to design the 'grok' namespace carefully; are you
> skeptical of this namespace in a Zope 2 context or a Zope 3 context or
Skeptical in a reuse (library, component) context, which you discovered
>> IOW, I think code written with grok might be kept clean and compatible
>> with both Z2 and Z3 (without "try except ImportError").
> Ah, this is perhaps your primary reason not to use the "grok" namespace
> in a Zope 2 context?
> This then appears to be a choice between code reuse and the reuse of a
> single API we're trying to design and control. If you agree that people
> who use Grok itself directly should be using 'grok' and not the
> underlying packages, I think it would be good to allow people to do the
> same in a Zope 2 context.
Which is what I told above.
Making it work that way in Z2 is fine as long as we can keep the other
> Checking for an ImportError somewhere seems unavoidable, but it can be
> abstracted away. What about a grokcompat module that will get you the
> right Grok?
> import grok
> except ImportError
> from five import grok
> That said, the situation is different for library code that knows it's
> just ever going to need grokcore.component. If you are writing a library
> that should be usable in a very wide context (Zope 2, straight Zope 3,
> Grok, perhaps even plain Python), a direct dependency on the underlying
> libraries makes sense.
Which is exactly what I had in mind.
> If you are writing a Zope 2 application which will have to call Zope 2
> APIs a dependence on 'from five import grok' (or grokcompat perhaps)
> seems the right way to do however.
Definitely. Thanks for making my thoughts clear !
(I am still much better expressing myself orally than with keyboard :-)
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
More information about the Grok-dev