Re: [Zope-dev] How to override __getattr__ and not break acquisition

2002-10-17 Thread John Barratt
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

Re: [Zope-dev] How to override __getattr__ and not break acquisition

2002-10-17 Thread John Barratt
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

Re: [Zope-dev] Catalog performance

2003-09-10 Thread John Barratt
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

Re: [Zope-dev] Re: Catalog performance

2003-09-10 Thread John Barratt
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

Re: [Zope-dev] Catalog performance

2003-09-11 Thread John Barratt
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

Re: [Zope-dev] Catalog performance

2003-09-21 Thread John Barratt
[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.

ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)

2005-06-06 Thread John Barratt
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

Re: [Zope-Coders] ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)

2005-06-07 Thread John Barratt
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

Re: ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)

2005-06-09 Thread John Barratt
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)

Re: ZClass problem in 2.8 (Was: Re: [Zope-dev] Upcoming Zope 2.8 release)

2005-06-13 Thread John Barratt
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