Summary of messages to the zope-tests list.
Period Sat Mar 3 12:00:00 2007 UTC to Sun Mar 4 12:00:00 2007 UTC.
There were 7 messages: 7 from Zope Unit Tests.
Tests passed OK
---
Subject: OK : Zope-2.6 Python-2.1.3 : Linux
From: Zope Unit Tests
Date: Sat Mar 3 21:03:46 EST 2007
URL
I'm forwarding a message from limi here, since it makes much more sense
here than it does on plone-developers. To summarize it: while analying
performance of the Plone 3 codebase they noticed a lot of time was spent
trying to figure out which types could be added at a location. Part of
that logic u
--On 4. März 2007 13:57:23 +0100 Wichert Akkerman <[EMAIL PROTECTED]>
wrote:
I'm forwarding a message from limi here, since it makes much more sense
here than it does on plone-developers. To summarize it: while analying
performance of the Plone 3 codebase they noticed a lot of time was spent
Previously Andreas Jung wrote:
> --On 4. März 2007 13:57:23 +0100 Wichert Akkerman <[EMAIL PROTECTED]>
> wrote:
>
> >I'm forwarding a message from limi here, since it makes much more sense
> >here than it does on plone-developers. To summarize it: while analying
> >performance of the Plone 3 code
Previously Wichert Akkerman wrote:
> http://paste.plone.org/13217 should do the trick. It makes
> _product_packages cache its result using the list of products in
> Control_Panel as a cache key. That makes sure that removing or adding
> products there will not result in stale data being returned by
Mutable default values are evil. I would get rid of that.
--
Sidnei da Silva
Enfold Systemshttp://enfoldsystems.com
Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/ma
Previously Sidnei da Silva wrote:
> Mutable default values are evil. I would get rid of that.
I modeled that on how get_module_info worked, so at least the pattern is
not new in the Zope2 codebase. It could just as easily be done in a
global value as well. I'm more interested in seeing if people a
Looking at the changes rocky made, I don't see why allowing external
methods from non-Products should require making the whole process
completely dynamic on every call. The old mechanism of storing the
product list should be put back in place, along with the addition of
non-Product information to
On Mar 4, 1:49 pm, "Alec Mitchell" <[EMAIL PROTECTED]> wrote:
> Looking at the changes rocky made, I don't see why allowing external
> methods from non-Products should require making the whole process
> completely dynamic on every call. The old mechanism of storing the
> product list should be put