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
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 2.7
[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
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 m
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
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.
> 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 '
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 i
Steve,
Thanks for the reply.
Steve Alexander wrote:
> Sounds like you could use ZPatterns.
We already use ZPatterns, but that doesn't seem to fit in at the right
layer unfortunately. To further clarify...
I am trying to do something similar to what is implemented in Dieter
Maurer's 'Reference
Oliver,
Thanks for the reply.
Oliver Bleutgen wrote:
> > def __getattr__(self,attr):
> > if name = 'foo':
> > return self.foo()
> >
> > return Implicit.__class__.__getattr__(self,attr)
>
> If you really want to do just that, take a look at ComputedAttribute,
> just in case you do
m Implicit, so I would have thought this would be OK.
Anyone with any thoughts/pointers?
TIA,
JB.
John Barratt wrote:
>
> Dragging up and old topic here... But I am attempting something similar
> here with no success.
>
> Basically I want to do something like was demonstrated (us
Dragging up and old topic here... But I am attempting something similar
here with no success.
Basically I want to do something like was demonstrated (using python
2.1, Zope 2.5.1), but to call the 'default' __getattr__ subsequently so
that I can put in my own handlers, before looking for 'standar
14 matches
Mail list logo
