On 3/20/11 16:03 , Wichert Akkerman wrote:
> On 3/20/11 16:00 , Hanno Schlichting wrote:
>> On Sun, Mar 20, 2011 at 3:28 PM, Jim Fulton<j...@zope.com>   wrote:
>>> - The mechanism shouldn't require something to "grok"/analyze the
>>>    code.  The mechanism should be explicit. This is implied by
>>>    "pythonic".  I remember Grok being more implicit than skimming the
>>>    links above suggest. Perhaps Grok has has become more explicit than
>>>    I remember.
>> Both Grok and Pyramid (or martian and venusian really) do a scan of
>> the code to find the registration hints.
> Pyramid only does so if you tell it to do so by using config.scan(). You
> are not obliged to do that, and I have several pyramid projects which do
> not do any scanning. Not doing scanning has the advantage of making
> configuration more explicit, and it speeds application startup immensely.

Let me try to argue this better. Downsides of scanning are:

- it scans your tests, which can result in unexpected behaviour you
   may not expect (at least for venusian, not sure if this is true for
- you may have some draft files in your tree that are not ready for use
   and never referenced anywhere, but a scan will still process them.
- scanning can take a long time, making application (re)start slow for
   non-trivial projects
- problems in the scanning process tend to be very hard debug. If a
   view is not processed during scanning figuring out why can be
   painful, and there are little to no tools to help you. This is
   especially true for more complex scanning environments such as the
   plone/dexterity/z3cform stack; as an example I spent over an hour
   yesterday trying to figure out why a form was not picked up while
   other views in the same python file worked fine.

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to