[Grok-dev] Re: five.grok

[Godefroid Chapelle]

Martijn Faassen wrote:
> 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?

Skeptical in a reuse (library, component) context, which you discovered 
below.

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

It is.

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

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

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 :-)


> 
> Regards,
> 
> Martijn


-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be