[Grok-dev] Re: five.grok

[Martijn Faassen]

Godefroid Chapelle wrote:
[snip]
> 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):
      pass

   class Bar(View):
      pass

so that people can see "what is coming from where"?

instead of:

   import grok

   class Foo(grok.Adapter):
     pass

   class Bar(grok.View):
     pass

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?

[snip]
> 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?

grokcompat.py

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

Regards,

Martijn