On Mon, Mar 2, 2009 at 9:59 AM, Martijn Faassen wrote:
>> Also, is there any caching for already processed packages in the
>> include finder code? If no, I'd probably like to contribute some, if
>> I'll use z3c.autoinclude. :)
>
> Ah, you're thinking in the same direction. I don't think there's an
Hey,
On Sat, Feb 28, 2009 at 5:02 PM, Ethan Jucovy wrote:
[snip]
> The only times I've used it so far have been just for fun though --
> turning off autoinclusion somewhere to see what breaks. :)
Dan just came up with a good use case for the feature, so now I'm glad
you added it. :) It's useful
Hi there,
On Sat, Feb 28, 2009 at 3:14 PM, Dan Korostelev wrote:
> 2009/2/26 Martijn Faassen :
[snip]
>> When claims like that are made, I'd like to see measurements that
>> demonstrate significant slowdowns during startup. Undoubtedly more
>> code is excuted than when you write out 'include' dir
On Fri, Feb 27, 2009 at 10:35 AM, Martijn Faassen
wrote:
> Hey,
>
> On Thu, Feb 26, 2009 at 5:32 PM, Ethan Jucovy wrote:
>> That's true on paper, but in practice z3c.autoinclude's *indirection*
>> does make a difference when you're just trying to debug what's going
>> on.
>
> If something goes wr
2009/2/26 Martijn Faassen :
> Hey,
>
> On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev wrote:
> [snip]
>>> (note though that including an extra "meta.zcml" can be avoided if you
>>> make use of the z3c.autoinclude library)
>>
>> Yep, I know about z3c.autoinclude, but I don't like it, as it makes
Hey,
On Thu, Feb 26, 2009 at 5:32 PM, Ethan Jucovy wrote:
> On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen
> wrote:
[snip]
>> That's asking for a feature that other packages that *don't* use
>> autoinclude don't support! You lose control as soon as you include a
>> package's "configure.zcml".
On Thu, Feb 26, 2009 at 7:07 AM, Martijn Faassen wrote:
> Hey,
>
> On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev wrote:
>> Yep, I know about z3c.autoinclude, but I don't like it, as it makes
>> things more implicit and it also
>
> Yes, automation makes things more implicit. This is *not* an ar
2009/2/26 Jim Fulton :
>
>> and make the "exclude" directive
>> from zc.configuration point to the zope.configuration's implementation
>> making the original place deprecated (however I guess the whole
>> zc.configuration package should't be deprecated as it's intended to be
>> a common place for c
On Feb 26, 2009, at 5:26 AM, Dan Korostelev wrote:
> Hi there.
>
> The "exclude" directive provided by zc.configuration package is easy
> to use and straightforward. I think it's used almost in every
> zope-based application setup. Its implementation is very small and
> fits great in zope.configu
Hey,
On Thu, Feb 26, 2009 at 12:43 PM, Dan Korostelev wrote:
[snip]
>> (note though that including an extra "meta.zcml" can be avoided if you
>> make use of the z3c.autoinclude library)
>
> Yep, I know about z3c.autoinclude, but I don't like it, as it makes
> things more implicit and it also
Yes
2009/2/26 Martijn Faassen :
> Dan Korostelev wrote:
>> The "exclude" directive provided by zc.configuration package is easy
>> to use and straightforward. I think it's used almost in every
>> zope-based application setup.
>
> I highly doubt so; I don't find myself using it a lot myself, for
> insta
Hey,
Dan Korostelev wrote:
> The "exclude" directive provided by zc.configuration package is easy
> to use and straightforward. I think it's used almost in every
> zope-based application setup.
I highly doubt so; I don't find myself using it a lot myself, for
instance. :)
> Its implementation i
Hi there.
The "exclude" directive provided by zc.configuration package is easy
to use and straightforward. I think it's used almost in every
zope-based application setup. Its implementation is very small and
fits great in zope.configuration's standard directives. So I'd like to
propose to move it
13 matches
Mail list logo
