Jo Meder wrote:
A long time ago, Shane posted a very useful function
to analyse acquisition wrappers: showaq.
Maybe, the mailing list archive is still able to locate his post...
Just ask Google: http://www.zope.org/Members/chrisw/showaq
Thanks Jo. It seems though that there was a branch
Dieter Maurer wrote:
Looks like an acquisition bug:
obj.aq_inContextOf(context, 1) is recursively defined by:
True, if obj.aq_base == context.aq_base
or container(obj) is not None
and container(obj).aq_inContextOf(context, 1)
where container(obj)
Andreas Jung wrote:
According to Jim ZClasses are working. A possibly isolated bug in
ZClasses is bad but there are in general lots of such bugs in Zope. So
this is not a release stopper for me now.
As far as I can see this is either a serious bug with respect to
ZClasses in that they just
Andreas Jung wrote:
[EMAIL PROTECTED] wrote:
What about the ZClasses?
Jim fixed them (hopefully :-))
They don't work for me in 2.8... :-(
I can't shake a new permission problem when trying to add a ZClass
instance in 2.8b2. This is a 2.8 specific problem as the same process
works in
[EMAIL PROTECTED] wrote:
Just my 2 cents observation...
I ran this code and monitored the page Cache extreme detail in ZMI
ControlPanel DebugInfo.
With this method, the object was not loaded. However the intermediate
objects that the unrestrictedTraverse() passed by were loaded into memory.
e.g.
Chris Withers wrote:
John Barratt wrote:
docs = container.portal_catalog(meta_type='Document', ...)
for doc in docs:
obj = doc.aq_parent.unrestrictedTraverse(doc.getPath())
was_ghost = obj._p_changed is None
value = obj.attr
if was_ghost:obj._p_deactivate()
Bear in mind though
Max M wrote:
Nguyen Quan Son wrote:
Hi,
I have a problem with performance and memory consumption when trying
to do some statistics, using following code:
...
docs = container.portal_catalog(meta_type='Document', ...)
for doc in docs:
obj = doc.getObject()
value = obj.attr
Simon Michael wrote:
John Barratt wrote:
the problem (which seems likely) then you can ghostify the objects
that were ghosts to begin with, and it will save memory (unless all
those objects are already in cache).
This is rather interesting, but I don't quite follow what's happening
Casey Duncan wrote:
__getattr__ hooks are evil, only to be used as a last resort. Are you So I've found,
and heard! It didn't stop me from tyring, and I still don't see why they should be
so hard so work with, difficult perhaps, but I wouldn't have though you needed to
pull the seemingly
There is no default or normal __getattr__. __getattr__ is defined only
when you need abnormal ways of getting an attribute.
Do you mean it only gets defined when standard (instance class based)
searching methods fail?
If I try a similar thing to this, I always end up getting the 'old' one
10 matches
Mail list logo
