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<[email protected]> 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 martian). - 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. Wichert. _______________________________________________ Zope-Dev maillist - [email protected] https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
