[Grok-dev] Re: five.grok

Martijn Faassen faassen at startifact.com
Fri Aug 1 09:58:25 EDT 2008

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 both?

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

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.

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.



More information about the Grok-dev mailing list